In article 551e2cfd$0$11123$c3e8...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 steve+comp.lang.pyt...@pearwood.info
On Friday, March 13, 2015 at 5:36:35 PM UTC+8, Marko Rauhamaa wrote:
Rustom Mody rustompm...@gmail.com:
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
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 steve+comp.lang.pyt...@pearwood.info wrote:
The biggest difference is syntactic. Here's an iterator which returns a
never-ending sequence of squared
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, and
In article 83d579c1-ab61-4a3d-a834-e65d28eac...@googlegroups.com,
Rustom Mody rustompm...@gmail.com 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
In article mailman.372.1427809109.10327.python-l...@python.org,
Dave Angel da...@davea.name 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 steve+comp.lang.pyt...@pearwood.info wrote:
The biggest
On Wed, Apr 1, 2015 at 2:03 AM, Albert van der Horst
alb...@spenarnc.xs4all.nl 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
In article 55062bda$0$12998$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Is it necessary/useful for a Python
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 steve+comp.lang.pyt...@pearwood.info wrote:
The biggest difference is syntactic. Here's an iterator which returns a
never-ending sequence of squared numbers 1,
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
-
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:
==
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.
Acceptable?
On Mon, 16 Mar 2015 19:52:59 -0700 (PDT), Rustom Mody
rustompm...@gmail.com 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
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
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 years are past.
I
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 is so simple?
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',
Rustom Mody rustompm...@gmail.com:
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
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
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
steve+comp.lang.pyt...@pearwood.info 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
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
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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
(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
Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa ma...@pacujo.net 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
Chris Angelico wrote:
On Mon, Mar 16, 2015 at 7:36 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
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 read
Ian Kelly ian.g.ke...@gmail.com:
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
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:
def
On Mon, Mar 16, 2015 at 9:09 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
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
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 of type.
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 Mon, Mar 16, 2015 at 8:32 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
Ian Kelly ian.g.ke...@gmail.com:
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
On Mon, Mar 16, 2015 at 7:39 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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
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 around the docs
On Mon, Mar 16, 2015 at 1:12 AM, Marko Rauhamaa ma...@pacujo.net 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa ma...@pacujo.net 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
Chris Angelico ros...@gmail.com:
On Mon, Mar 16, 2015 at 6:12 PM, Marko Rauhamaa ma...@pacujo.net 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
Ian Kelly ian.g.ke...@gmail.com:
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
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]
On Monday 16 March 2015 18:12, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
On Mon, Mar 16, 2015 at 7:36 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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 pines
You
Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa ma...@pacujo.net 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
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
Oscar Benjamin oscar.j.benja...@gmail.com:
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
On 12 March 2015 at 16:52, Rustom Mody rustompm...@gmail.com 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)
If I look
On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Oscar Benjamin oscar.j.benja...@gmail.com:
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
On Sun, Mar 15, 2015 at 11:48 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa ma...@pacujo.net wrote:
What features do generator iterators provide on top of generic
iterators?
You can send values into them, throw
Chris Angelico ros...@gmail.com:
On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa ma...@pacujo.net 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
On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Is it necessary/useful for a Python application programmer to be
conscious of the different types of iterator? What
Chris Angelico ros...@gmail.com:
On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa ma...@pacujo.net 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
On Sat, Mar 14, 2015 at 1:54 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
Marko Rauhamaa wrote:
Your 'factory' is a:
generator
A function which returns an iterator.
URL: https://docs.python.org/3/glossary.html
That
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
Marko Rauhamaa wrote:
Your 'factory' is a:
generator
A function which returns an iterator.
URL: https://docs.python.org/3/glossary.html
That glossary entry is misleading, or at least incomplete, and it fails to
match the way generator is used by actual Python programmers.
On 14/03/2015 07:54, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
Marko Rauhamaa wrote:
Your 'factory' is a:
generator
A function which returns an iterator.
URL: https://docs.python.org/3/glossary.html
That glossary entry is misleading, or
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
Marko Rauhamaa wrote:
Your 'factory' is a:
generator
A function which returns an iterator.
URL: https://docs.python.org/3/glossary.html
That glossary entry is misleading, or at least incomplete, and it
fails to match
Mark Lawrence breamore...@yahoo.co.uk:
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.
On 03/14/2015 12:51 PM, Chris Angelico wrote:
On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody rustompm...@gmail.com 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
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 and
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 function
On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody rustompm...@gmail.com 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
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
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 a
On Sun, Mar 15, 2015 at 2:29 AM, Rustom Mody rustompm...@gmail.com 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
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 pineapple
On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody rustompm...@gmail.com 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
On Friday, March 13, 2015 at 1:53:50 PM UTC+5:30, Chris Angelico wrote:
On Fri, Mar 13, 2015 at 4:28 PM, Rustom Mody wrote:
And even there I would expect generators to close with StopIteration
Whereas I would expect coroutines to close (on close method) with
GeneratorExit
[Ive not
Rustom Mody rustompm...@gmail.com:
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
you try to come up with something better.
When I say expect
On Fri, Mar 13, 2015 at 4:28 PM, Rustom Mody rustompm...@gmail.com wrote:
And even there I would expect generators to close with StopIteration
Whereas I would expect coroutines to close (on close method) with
GeneratorExit
[Ive not thought all this through properly so may be off the mark]
I
On Fri, Mar 13, 2015 at 8:12 PM, Rustom Mody rustompm...@gmail.com wrote:
On Friday, March 13, 2015 at 1:53:50 PM UTC+5:30, Chris Angelico wrote:
On Fri, Mar 13, 2015 at 4:28 PM, Rustom Mody wrote:
And even there I would expect generators to close with StopIteration
Whereas I would expect
This is more a question about standard terminology/conventions than about
semantics - of course assuming I understand :-)
Say I have a simple yielding function:
def foo(x):
yield x+1
yield x+2
And I have
g = foo(2)
If I look at type, g's type is 'generator' whereas foo is just plain-ol
On Fri, Mar 13, 2015 at 12:35 AM, Rustom Mody rustompm...@gmail.com wrote:
If I look at type, g's type is 'generator' whereas foo is just plain-ol
'function.'
Whereas in informal usage we say foo is a generator.
So the question:
What should we call foo and what should we call g?
g is a
On Thursday, March 12, 2015 at 1:35:48 PM UTC, Rustom Mody wrote:
This is more a question about standard terminology/conventions than about
semantics - of course assuming I understand :-)
Say I have a simple yielding function:
def foo(x):
yield x+1
yield x+2
And I have
g =
On Friday, March 13, 2015 at 9:00:17 AM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Thursday, March 12, 2015 at 11:25:32 PM UTC+5:30, Marko Rauhamaa wrote:
Rustom Mody :
I guess we need
1. A clear ontology of the base concepts (which is a buzzword for
nailed-down
Rustom Mody wrote:
On Thursday, March 12, 2015 at 11:25:32 PM UTC+5:30, Marko Rauhamaa wrote:
Rustom Mody :
I guess we need
1. A clear ontology of the base concepts (which is a buzzword for
nailed-down terminology)
According to the documentation, a function whose definition contains
On Thursday, March 12, 2015 at 11:25:32 PM UTC+5:30, Marko Rauhamaa wrote:
Rustom Mody :
I guess we need
1. A clear ontology of the base concepts (which is a buzzword for
nailed-down terminology)
According to the documentation, a function whose definition contains a
yield statement is
Rustom Mody wrote:
This is more a question about standard terminology/conventions than about
semantics - of course assuming I understand :-)
Say I have a simple yielding function:
def foo(x):
yield x+1
yield x+2
And I have
g = foo(2)
If I look at type, g's type is
Guess I should be pleased that I am doing as good as you (and Chris) describe.
For some reason or not I am not...
On Thursday, March 12, 2015 at 9:58:07 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
This is more a question about standard terminology/conventions than about
Terry Reedy tjre...@udel.edu:
On 3/12/2015 9:35 AM, Rustom Mody wrote:
This is more a question about standard terminology/conventions than
about semantics - of course assuming I understand :-)
Say I have a simple yielding function:
def foo(x):
yield x+1
yield x+2
This is a
On 3/12/2015 9:35 AM, Rustom Mody wrote:
This is more a question about standard terminology/conventions than about
semantics - of course assuming I understand :-)
Say I have a simple yielding function:
def foo(x):
yield x+1
yield x+2
This is a generator function
And I have
g =
Rustom Mody rustompm...@gmail.com:
I guess we need
1. A clear ontology of the base concepts (which is a buzzword for
nailed-down terminology)
According to the documentation, a function whose definition contains a
yield statement is a generator:
Using a yield expression in a function’s
86 matches
Mail list logo
