> To get the individual lines you have to yield them
>
> for line in lines_gen:
> yield line
>
> This can be rewritten with some syntactic sugar as
>
> yield from lines_gen
>
> > for line in getWord(fileName, 5):
> > with open(dumpName, 'a') as f:
> >
Sayth Renshaw wrote:
> Afternoon
>
> Trying to create a generator to write the first N lines of text to a file.
> However, I keep receiving the islice object not the text, why?
>
> from itertools import islice
>
> fileName = dir / "7oldsamr.txt"
> dumpName = dir / "dump.txt"
>
> def getWord(in
Wow, thank you Ian for this very detailed answer, and thank you for taking the
time for that! Much appreciated!
If I get this right, I have to somehow fix the value of a_list during the loop,
like when you use the classic default value argument trick with lambdas (damn, I
should have thought of th
Le 14/03/19 à 10:45, Peter Otten a écrit :
> Pierre Reinbold wrote:
>
>> Wow, thank you Ian for this very detailed answer, and thank you for taking
>> the time for that! Much appreciated!
>>
>> If I get this right, I have to somehow fix the value of a_list during the
>> loop, like when you use the
Pierre Reinbold wrote:
> Wow, thank you Ian for this very detailed answer, and thank you for taking
> the time for that! Much appreciated!
>
> If I get this right, I have to somehow fix the value of a_list during the
> loop, like when you use the classic default value argument trick with
> lambda
Wow, thank you Ian for this very detailed answer, and thank you for taking the
time for that! Much appreciated!
If I get this right, I have to somehow fix the value of a_list during the loop,
like when you use the classic default value argument trick with lambdas (damn, I
should have thought of th
You're basically running into this:
https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result
To see why, let's try disassembling your function. I'm using Python 3.5
here, but it shouldn't make much of a difference.
py> import
Sayth Renshaw wrote:
> Thanks.
>
> I left "base" out as i was trying to remove as much uneeded code from
> example as possible. I had defined it as
>
> base = datetime.datetime(2017,1,1)
You actually did provide that line in your post.
> Reading your code this sounds to simple :-).
>
> def da
Thanks.
I left "base" out as i was trying to remove as much uneeded code from example
as possible. I had defined it as
base = datetime.datetime(2017,1,1)
Reading your code this sounds to simple :-).
def dates(first, numdays):
# generate datetime objects for extra clarity
# note ther
"Sayth Renshaw" wrote in message
news:328f42bb-ba23-4199-9f3a-9ec1829bc...@googlegroups.com...
Hi
I am struggling to figure out how I can create a generator to provide
values to my url. My url needs to insert the year month and day in the url
not as params to the url.
import json
import re
Sayth Renshaw wrote:
> Hi
>
> I am struggling to figure out how I can create a generator to provide
> values to my url. My url needs to insert the year month and day in the url
> not as params to the url.
>
>
> import json
> import requests
> import datetime
>
> # using this I can create a lis
On Wed, Jun 7, 2017 at 10:00 AM, Rob Gaddi
wrote:
>
> On 06/06/2017 11:13 PM, Frank Millman wrote:
>>
>> Hi all
>>
>> It would be nice to write a generator in such a way that, in addition to
'yielding' each value, it performs some additional work and then 'returns'
a final result at the end.
>>
>>
On 06/06/2017 11:13 PM, Frank Millman wrote:
Hi all
It would be nice to write a generator in such a way that, in addition to
'yielding' each value, it performs some additional work and then
'returns' a final result at the end.
From Python 3.3, anything 'returned' becomes the value of the
St
On 07Jun2017 19:19, Steve D'Aprano wrote:
Frank Millman writes:
It would be nice to write a generator in such a way that, in addition
to 'yielding' each value, it performs some additional work and then
'returns' a final result at the end.
From Python 3.3, anything 'returned' becomes the value
On Wed, 7 Jun 2017 05:09 pm, Jussi Piitulainen wrote:
> Frank Millman writes:
>
>> It would be nice to write a generator in such a way that, in addition
>> to 'yielding' each value, it performs some additional work and then
>> 'returns' a final result at the end.
>>
>>> From Python 3.3, anything
"Jussi Piitulainen" wrote:
Frank Millman writes:
> It would be nice to write a generator in such a way that, in addition
> to 'yielding' each value, it performs some additional work and then
> 'returns' a final result at the end.
>
> From Python 3.3, anything 'returned' becomes the value of th
Frank Millman writes:
> It would be nice to write a generator in such a way that, in addition
> to 'yielding' each value, it performs some additional work and then
> 'returns' a final result at the end.
>
>> From Python 3.3, anything 'returned' becomes the value of the
>> StopIteration
> exceptio
Thank you quite easy, was trying to work around it in the generator, the print
needs to be outside the generator to avoid the collection of "None".
Wasn't really liking comprehensions though python 3 dict comprehensions are a
really nice utility.
Sayth
--
https://mail.python.org/mailman/listi
On Tue, Oct 18, 2016 at 11:57 PM, Jon Ribbens wrote:
> I must admit I find the idea of enumerate(range(n)) quite pleasing.
> gotta keep track of which numbers those numbers are!
Heh! I'm assuming that's a placeholder for
enumerate(some_other_iterable), where the actual iterable in question
isn't
On 2016-10-18, Steve D'Aprano wrote:
> On Tue, 18 Oct 2016 10:43 pm, Sayth Renshaw wrote:
>> I was solving a problem to create a generator comprehension with 'Got '
>> and a number for each in range 10.
>>
>> This I did however I also get a list of None. I don't understand where
>> none comes fro
On Tue, 18 Oct 2016 10:43 pm, Sayth Renshaw wrote:
> I was solving a problem to create a generator comprehension with 'Got '
> and a number for each in range 10.
>
> This I did however I also get a list of None. I don't understand where
> none comes from. Can you please clarify?
You get None bec
Sayth Renshaw writes:
> This I did however I also get a list of None. I don't understand where
> none comes from. Can you please clarify?
Every function in Python, if it returns, returns a value.
In an expression that consists of only a function call, the expression
resolves to the return value
On Oct 18, 2016 7:45 AM, "Sayth Renshaw" wrote:
>
> I was solving a problem to create a generator comprehension with 'Got '
and a number for each in range 10.
>
> This I did however I also get a list of None. I don't understand where
none comes from. Can you please clarify?
>
> a = (print("Got {0}
On Tue, Oct 18, 2016 at 10:43 PM, Sayth Renshaw wrote:
> I was solving a problem to create a generator comprehension with 'Got ' and a
> number for each in range 10.
>
> This I did however I also get a list of None. I don't understand where none
> comes from. Can you please clarify?
>
> a = (pri
Sayth Renshaw wrote:
def dataAttr(roots):
"""Get the root object and iter items."""
with open("output/first2.csv", 'w', newline='') as csvf:
race_writer = csv.writer(csvf, delimiter=',')
for meet in roots.iter("meeting"):
The value of roots you're passing in here is a ge
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
Loving life.
I first started with a simple with open on a file, which allowed me to use code
that "iter"'s.
for example:
for meet in root.iter("meeting"):
for race in root.ite
On Sat, 1 Oct 2016 06:52 pm, Sayth Renshaw wrote:
> Evening
>
> My file list handler I have created a generator.
>
> Before I created it as a generator I was able to use iter on my lxml root
> objects, now I cannot iter.
lxml root objects have an iter method. Other objects do not.
Thank you f
2016-10-01 12:09 GMT+02:00 Sayth Renshaw :
> My main issue is that usually its just x in ,,, for a generator.
>
> But if I change the code
> for meet in roots.iter("meeting"):
>
> to
> for meet in roots("meeting"):
>
> Well its invalid but I need to be able to reference the node, how do I
> achiev
My main issue is that usually its just x in ,,, for a generator.
But if I change the code
for meet in roots.iter("meeting"):
to
for meet in roots("meeting"):
Well its invalid but I need to be able to reference the node, how do I achieve
this?
Sayth
--
https://mail.python.org/mailman/listinfo/
This seems to work as a starter.
def return_files(file_list):
""" Take a list of files and return file when called
Calling function to supply attributes
"""
for filename in sorted(file_list):
with open(dir_path + filename) as fd:
doc = xmltodict.parse(f
> The way I'm reading your code, it's not the generator that's the
> difference here. Consider these lines:
>
> > for item in doc['meeting']['race']:
> >
> > def return_files(file_list):
> > for filename in sorted(file_list, *attribs):
> > for item in doc([attribs]):
>
>
On Sun, Sep 11, 2016 at 10:46 AM, Sayth Renshaw wrote:
> Hi
>
> I want to create a generator function that supplies my calling function a
> file, how though do I get the generator to accept attributes in the argument
> when called?
>
> This works not as a generator
The way I'm reading your code
On Friday, March 13, 2015 at 5:36:35 PM UTC+8, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > Nice demo of the same confusing terminology we are talking about.
>
> Why don't you just stick with the terminology of the language
> specification? I think your students are going to be more confused if
>
In article <551e2cfd$0$11123$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
>On Wednesday 01 April 2015 00:18, Albert van der Horst wrote:
>
>> In article <55062bda$0$12998$c3e8da3$54964...@news.astraweb.com>,
>> Steven D'Aprano wrote:
>
>>>The biggest difference is syntactic. Here's an ite
alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> You should give an example of usage. As a newby I'm not up to
> figuring out the specification from source for
> something built of the mysterious __ internal
> thingies.
In reality because of generator expressions, the yield statement, an
On Wednesday 01 April 2015 00:18, Albert van der Horst wrote:
> In article <55062bda$0$12998$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>>The biggest difference is syntactic. Here's an iterator which returns a
>>never-ending sequence of squared numbers 1, 4, 9, 16, ...
>>
>>c
On Wed, Apr 1, 2015 at 2:03 AM, Albert van der Horst
wrote:
> class Squares:
> def __init__(self):
> self.i = 0
> def __next__(self):
> self.i += 1
> return self.i**2
> def __iter__(self):
> return self
>
> albert@cherry:/tmp$ python
> Python 2.6.6 (r266
In article ,
Dave Angel wrote:
>On 03/31/2015 09:18 AM, Albert van der Horst wrote:
>> In article <55062bda$0$12998$c3e8da3$54964...@news.astraweb.com>,
>> Steven D'Aprano wrote:
>
>>>
>>> The biggest difference is syntactic. Here's an iterator which returns a
>>> never-ending sequence of squar
On 03/31/2015 09:18 AM, Albert van der Horst wrote:
In article <55062bda$0$12998$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
The biggest difference is syntactic. Here's an iterator which returns a
never-ending sequence of squared numbers 1, 4, 9, 16, ...
class Squares:
In article <55062bda$0$12998$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
>Marko Rauhamaa wrote:
>
>> Chris Angelico :
>>
>>> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa wrote:
Is it necessary/useful for a Python application programmer to be
conscious of the differen
In article <83d579c1-ab61-4a3d-a834-e65d28eac...@googlegroups.com>,
Rustom Mody wrote:
>On Saturday, March 14, 2015 at 8:59:22 PM UTC+5:30, Rustom Mody wrote:
>> On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano wrote:
>> >
>> > A generator (function) may be a function which re
On 17/03/2015 03:33, Rustom Mody wrote:
On Tuesday, March 17, 2015 at 8:55:27 AM UTC+5:30, Mark Lawrence wrote:
On 17/03/2015 03:18, Rustom Mody wrote:
On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
Ok Let me throw out a suggestion:
- potato is a generator
- t
On Tuesday, March 17, 2015 at 8:55:27 AM UTC+5:30, Mark Lawrence wrote:
> On 17/03/2015 03:18, Rustom Mody wrote:
> > On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
> >>>
> >>> Ok Let me throw out a suggestion:
> >>>- potato is a generator
> >>>- tomato is a cursor.
On 17/03/2015 03:18, Rustom Mody wrote:
On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
Ok Let me throw out a suggestion:
- potato is a generator
- tomato is a cursor.
Acceptable?
No. In Python potato is a generator function, tomato is a generator.
Why complica
On Mon, 16 Mar 2015 19:52:59 -0700 (PDT), Rustom Mody
wrote:
>
>When we go from 'simple-generators' to coroutine-generators there seem to be
>bigger conceptual problems and implementation-gaffes.
>Quite frankly I hardly understand this part.
There's a line after which terminology just becomes pe
On Tuesday, March 17, 2015 at 8:37:25 AM UTC+5:30, Mark Lawrence wrote:
> >
> > Ok Let me throw out a suggestion:
> > - potato is a generator
> > - tomato is a cursor.
> > Acceptable?
> >
>
> No. In Python potato is a generator function, tomato is a generator.
> Why complicate something that
On 17/03/2015 02:52, Rustom Mody wrote:
On Monday, March 16, 2015 at 11:50:33 PM UTC+5:30, Mark Lawrence wrote:
On 16/03/2015 14:37, Rustom Mody wrote:
On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
On 16/03/2015 14:19, Rustom Mody wrote:
==
Anyways
On Monday, March 16, 2015 at 11:50:33 PM UTC+5:30, Mark Lawrence wrote:
> On 16/03/2015 14:37, Rustom Mody wrote:
> > On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
> >> On 16/03/2015 14:19, Rustom Mody wrote:
> >>> ==
> >>> Anyways...
> >>>
> >>> Yes 15
On 16/03/2015 14:37, Rustom Mody wrote:
On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
On 16/03/2015 14:19, Rustom Mody wrote:
==
Anyways...
Yes 15 years are past.
I dont expect the def can be revoked now.
[As far as I am concerned its a minor wart]
Ian Kelly :
> Or inversely I write a normal utility function that is called from
> coroutines, then later add a "yield from" to it, and now I have to go
> back and revise every place where it's called to make those use "yield
> from" as well.
That is actually quite awkward. Smooth interlocking of
On Mon, Mar 16, 2015 at 9:09 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> For generators, the descriptive keyword ("yield") could be buried
>> *anywhere* in that block. One can glance at a generator function and
>> fail to notice that it is a generator function. This is the one that
>> really bugs
Ian Kelly :
> For generators, the descriptive keyword ("yield") could be buried
> *anywhere* in that block. One can glance at a generator function and
> fail to notice that it is a generator function. This is the one that
> really bugs me about reuse of "def", although you are correct that
> this
On Monday, March 16, 2015 at 8:07:22 PM UTC+5:30, Rustom Mody wrote:
> I would gladly do that if it was a minor correction here and there.
> But the problem is a bit deeper even though it can be kept mostly¹ in the docs
> and not modify any syntax/semantics of python.
>
> In particular for:
>
> d
On Mon, Mar 16, 2015 at 7:39 AM, Steven D'Aprano
wrote:
> On Mon, 16 Mar 2015 11:51 pm, Rustom Mody wrote:
>
>> It may help to read this 15 year old thread starting
>> https://mail.python.org/pipermail/python-dev/2001-June/015478.html
>> to see how many python stalwarts dont like the current state
On Mon, Mar 16, 2015 at 8:32 AM, Steven D'Aprano
wrote:
> On Tue, 17 Mar 2015 12:13 am, Marko Rauhamaa wrote:
>
>> If I get an iterator from a black box source, I don't know if I'm
>> allowed/supposed to call close() on it.
>
> In no particular order:
>
> #1
> if hasattr(some_iterator, 'close'):
>
On Monday, March 16, 2015 at 7:57:08 PM UTC+5:30, Mark Lawrence wrote:
> On 16/03/2015 14:19, Rustom Mody wrote:
> > ==
> > Anyways...
> >
> > Yes 15 years are past.
> > I dont expect the def can be revoked now.
> > [As far as I am concerned its a minor wart]
> > But the mess ar
On Tue, 17 Mar 2015 01:35 am, Steven D'Aprano wrote:
> On Tue, 17 Mar 2015 01:19 am, Rustom Mody wrote:
>
>> On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
>>> And of course, from a comp science theoretic perspective,
>>> generators are a kind of subroutine, not a kind o
On Tue, 17 Mar 2015 01:19 am, Rustom Mody wrote:
> On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
>> And of course, from a comp science theoretic perspective,
>> generators are a kind of subroutine, not a kind of type.
>
> You just showed Marko a few posts back, that
> A
On 16/03/2015 14:19, Rustom Mody wrote:
On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
And of course, from a comp science theoretic perspective,
generators are a kind of subroutine, not a kind of type.
You just showed Marko a few posts back, that
A generator is a spec
On Tue, 17 Mar 2015 12:13 am, Marko Rauhamaa wrote:
> If I get an iterator from a black box source, I don't know if I'm
> allowed/supposed to call close() on it.
In no particular order:
#1
if hasattr(some_iterator, 'close'):
some_iterator.close()
#2
close = getattr(some_iterator, 'close',
On Monday, March 16, 2015 at 7:10:03 PM UTC+5:30, Steven D'Aprano wrote:
> And of course, from a comp science theoretic perspective,
> generators are a kind of subroutine, not a kind of type.
You just showed Marko a few posts back, that
A generator is a special case of an iterator.
And you wrote t
On Mon, 16 Mar 2015 11:51 pm, Rustom Mody wrote:
> It may help to read this 15 year old thread starting
> https://mail.python.org/pipermail/python-dev/2001-June/015478.html
> to see how many python stalwarts dont like the current state of affairs
/s/dont/didn't/
That's a fifteen year old thread,
On Mon, Mar 16, 2015 at 10:51 PM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
> Just for the record, it's not just name bindings that make a generator
> behave as a coroutine. E.g.:
>
> py> def co():
> ... print( (yield 1) + 2 )
> ...
> py> a = co()
> py> next(a)
> 1
> py> a.send(98)
> 100
Rustom Mody :
> On Monday, March 16, 2015 at 6:02:48 PM UTC+5:30, Marko Rauhamaa wrote:
>> So what we have now is:
>> (1) plain iterators
>> (2) generator iterators
>> (3) coroutine generator iterators
>
>> (1) and (2) are not unified, which I don't like.
>
> Can you expand on that a bit?
(
On Monday, March 16, 2015 at 6:02:48 PM UTC+5:30, Marko Rauhamaa wrote:
> So what we have now is:
>
> (1) plain iterators
>
> (2) generator iterators
>
> (3) coroutine generator iterators
>
> (1) and (2) are not unified, which I don't like.
Can you expand on that a bit?
It may help to
On 16.03.2015 13:02, Steven D'Aprano wrote:
> (To be honest, I'm not even sure what the use-case for close() on coroutines
> is in the first place. If you don't want to send any more items into it,
> just don't send any more items into it.)
Just like with file-likes, it is useful to clean up resou
Steven D'Aprano :
> (To be honest, I'm not even sure what the use-case for close() on
> coroutines is in the first place. If you don't want to send any more
> items into it, just don't send any more items into it.)
Without close(), you might leave resources hanging. See PEP 325:
Rejected in
Steven D'Aprano :
> If I .send() into either of the generators above, its a conceptual
> mistake and I should get an error. The fact that I don't is an
> implementation detail, and one which hopefully will be fixed.
So what we have now is:
(1) plain iterators
(2) generator iterators
(3)
Marko Rauhamaa wrote:
> Anyway, calling close() on an iterator can be a necessary requirement
> even in ordinary generator usage. Only now they have to know if the
> underlying iterator was sired by a generator or some other constructor.
Can you give an actual example of that?
(To be honest, I'm
Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa wrote:
>>>
>>> I was actually referring to the offered API. It still seems to me like
>>> all iterators could offer close(), send() and throw(). Why? To make all
>>> iterators drop-in replacements of ea
Chris Angelico wrote:
> On Mon, Mar 16, 2015 at 7:36 PM, Steven D'Aprano
> wrote:
>> I expect that the interpreter can tell the difference between
>>
>> yield spam
>>
>> and
>>
>> x = yield spam
>>
>> and only allow send(), close() and throw() on generators which include
>> the second for
On Mon, Mar 16, 2015 at 7:36 PM, Steven D'Aprano
wrote:
> I expect that the interpreter can tell the difference between
>
> yield spam
>
> and
>
> x = yield spam
>
> and only allow send(), close() and throw() on generators which include the
> second form. If it can't, then that's a limitat
On Monday 16 March 2015 18:12, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Marko Rauhamaa wrote:
>>> What features do generator iterators provide on top of generic
>>> iterators?
>>
>> The biggest difference is syntactic. Here's an iterator which returns a
>> never-ending sequence of squared n
Ian Kelly :
> If on the other hand these methods were to be added to the iterator
> protocol, it would just create unnecessary implementation overhead for
> the 99.99% of non-generator iterators that are under no illusions
> about the fact that they aren't coroutines.
Why should
(x for x in [
Chris Angelico :
> On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa wrote:
>>
>> I was actually referring to the offered API. It still seems to me like
>> all iterators could offer close(), send() and throw(). Why? To make all
>> iterators drop-in replacements of each other.
>
> [...]
>
> That jus
On Mon, Mar 16, 2015 at 1:12 AM, Marko Rauhamaa wrote:
> I was actually referring to the offered API. It still seems to me like
> all iterators could offer close(), send() and throw(). Why? To make all
> iterators drop-in replacements of each other.
The purpose of close, send and throw is to impl
On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa wrote:
>
> I was actually referring to the offered API. It still seems to me like
> all iterators could offer close(), send() and throw(). Why? To make all
> iterators drop-in replacements of each other.
>
> Then, you could also stop wondering what t
Steven D'Aprano :
> Marko Rauhamaa wrote:
>> What features do generator iterators provide on top of generic
>> iterators?
>
> The biggest difference is syntactic. Here's an iterator which returns a
> never-ending sequence of squared numbers 1, 4, 9, 16, ...
>
> class Squares:
> def __init__(se
Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa wrote:
>>> Is it necessary/useful for a Python application programmer to be
>>> conscious of the different types of iterator? What mistaken usage
>>> could arise if the application just treated all iter
Rustom Mody wrote:
> On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano
> wrote:
>>
>> A generator (function) may be a function which returns an iterator,...
>
> I find "generator-function" misleading in the same way that "pineapple"
> misleadingly suggests "apple that grows on
On Sunday, March 15, 2015 at 1:45:37 AM UTC+5:30, Ian wrote:
> Now which should be considered definitive, the language reference or
> the PEP? This question is not rhetorical; I don't know the answer.
> Regardless of the answer though, the PEP at least illuminates the
> design intent of the termino
On Sun, Mar 15, 2015 at 11:48 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa wrote:
>>> What features do generator iterators provide on top of generic
>>> iterators?
>>
>> You can send values into them, throw exceptions into them, and close
>> t
Chris Angelico :
> On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa wrote:
>> What features do generator iterators provide on top of generic
>> iterators?
>
> You can send values into them, throw exceptions into them, and close
> them (which is a special case of the latter).
Hm. I wonder why the
On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa wrote:
>>> Is it necessary/useful for a Python application programmer to be
>>> conscious of the different types of iterator? What mistaken usage
>>> could arise if the
Chris Angelico :
> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa wrote:
>> Is it necessary/useful for a Python application programmer to be
>> conscious of the different types of iterator? What mistaken usage
>> could arise if the application just treated all iterators as, well,
>> iterators?
>
On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa wrote:
> Oscar Benjamin :
>
>> A generator is a special type of iterator that results from generator
>> functions and generator expressions.
>
> Is it necessary/useful for a Python application programmer to be
> conscious of the different types of it
Oscar Benjamin :
> A generator is a special type of iterator that results from generator
> functions and generator expressions.
Is it necessary/useful for a Python application programmer to be
conscious of the different types of iterator? What mistaken usage could
arise if the application just tr
On 12 March 2015 at 16:52, Rustom Mody wrote:
>
> On Thursday, March 12, 2015 at 9:58:07 PM UTC+5:30, Steven D'Aprano wrote:
>> Rustom Mody wrote:
>>
>> >
>> > Say I have a simple yielding function:
>> >
>> > def foo(x):
>> >yield x+1
>> >yield x+2
>> >
>> > And I have
>> >
>> > g = foo(2)
On 14/03/2015 20:14, Ian Kelly wrote:
Now which should be considered definitive, the language reference or
the PEP? This question is not rhetorical; I don't know the answer.
Regardless of the answer though, the PEP at least illuminates the
design intent of the terminology.
The language refere
On Sat, Mar 14, 2015 at 1:54 AM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Marko Rauhamaa wrote:
>>
>>> Your 'factory' is a:
>>>
>>> generator
>>> A function which returns an iterator.
>>> https://docs.python.org/3/glossary.html>
>>
>> That glossary entry is misleading, or at
On Saturday, March 14, 2015 at 10:22:51 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody wrote:
> > As best as I can see python makes no distinction between such a foo and
> > the more usual function/methods that have no returns.
> > You can I can talk about these a
On 03/14/2015 12:51 PM, Chris Angelico wrote:
On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody wrote:
As best as I can see python makes no distinction between such a foo and
the more usual function/methods that have no returns.
You can I can talk about these and distinguish them
Python has no clue
On 14/03/2015 16:33, Rustom Mody wrote:
On Saturday, March 14, 2015 at 9:45:10 PM UTC+5:30, Chris Angelico wrote:
On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody wrote:
Causing all sorts of unnecessary confusions:
An int-function returns int and a char*-functions returns char*.
Does a void-functio
On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody wrote:
> As best as I can see python makes no distinction between such a foo and
> the more usual function/methods that have no returns.
> You can I can talk about these and distinguish them
> Python has no clue about it.
But what support is actually n
On Saturday, March 14, 2015 at 9:45:10 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody wrote:
> > Causing all sorts of unnecessary confusions:
> > An int-function returns int and a char*-functions returns char*.
> > Does a void-function return void??
> > No a void
On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody wrote:
> Causing all sorts of unnecessary confusions:
> An int-function returns int and a char*-functions returns char*.
> Does a void-function return void??
> No a void function doesn't return anything!
> Ah So a void function does a longjmp?
>
> All o
On Saturday, March 14, 2015 at 8:59:22 PM UTC+5:30, Rustom Mody wrote:
> On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano wrote:
> >
> > A generator (function) may be a function which returns an iterator,...
>
> I find "generator-function" misleading in the same way that "pine
On Sun, Mar 15, 2015 at 2:29 AM, Rustom Mody wrote:
> However a "generator function" is a weird sort of function (at best).
> Not regarding it as a function is IMO more reasonable.
But it *is* a function. You call it, possibly with positional and/or
keyword arguments, and you get back a returned
On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano wrote:
>
> A generator (function) may be a function which returns an iterator,...
I find "generator-function" misleading in the same way that "pineapple"
misleadingly suggests "apple that grows on pines"
A builtin function is
Mark Lawrence :
> On 14/03/2015 07:54, Marko Rauhamaa wrote:
>> I am an actual Python programmer (I develop Python programs) and my
>> definitive source for Python is the documentation. If there is an
>> error in the documentation, I would very much like it to be
>> corrected.
>
> Five minutes wor
1 - 100 of 380 matches
Mail list logo
