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
On 14/03/2015 07:54, 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 least incomplete, and it
fails to mat
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 least incomplete, and it
> fails to match the way "generator" is us
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 least incomplete, and it fails to
match the way "generator" is used by actual Python programmers.
On Fri, Mar 13, 2015 at 8:12 PM, Rustom Mody 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 coroutines to
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
you try to come up with something better.
> When I say "expect generators to close
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 n
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 thought all this through properly so may be off the mark]
I expect both of the
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
>
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 def
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 st
Terry Reedy :
> 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 ge
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 = foo
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 a generator:
Using a yield expression in a function’s body causes that funct
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
> > sem
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 ty
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
On Fri, Mar 13, 2015 at 12:35 AM, Rustom Mody 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 generator object;
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
86 matches
Mail list logo
