Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #87319 > unrolled thread

generator/coroutine terminology

Back to article view | Back to comp.lang.python

Contents

  generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-12 06:35 -0700
    Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-13 00:55 +1100
    Re: generator/coroutine terminology breamoreboy@gmail.com - 2015-03-12 06:57 -0700
    Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-13 03:27 +1100
      Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-12 09:52 -0700
        Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-12 19:55 +0200
          Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-12 19:23 -0700
            Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-13 14:30 +1100
              Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-12 22:28 -0700
                Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-13 19:23 +1100
                  Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-13 02:12 -0700
                    Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-13 11:36 +0200
                      Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-14 17:04 +1100
                        Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-14 09:54 +0200
                          Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-14 08:04 +0000
                            Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-14 10:30 +0200
                          Re: generator/coroutine terminology Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-14 14:14 -0600
                            Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-14 21:15 -0700
                          Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-14 20:31 +0000
                        Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-14 08:29 -0700
                          Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-15 02:56 +1100
                          Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-14 08:59 -0700
                            Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-15 03:14 +1100
                              Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-14 09:33 -0700
                                Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-15 03:51 +1100
                                  Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-14 10:17 -0700
                                Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-14 16:56 +0000
                                Re: generator/coroutine terminology Dave Angel <davea@davea.name> - 2015-03-14 13:07 -0400
                            Re: generator/coroutine terminology albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-31 12:57 +0000
                          Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-15 19:37 +1100
                      Re: generator/coroutine terminology CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-18 11:07 -0700
                    Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-13 22:32 +1100
        Re: generator/coroutine terminology Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-03-14 22:02 +0000
          Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-15 00:15 +0200
            Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-15 09:24 +1100
              Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-15 02:15 +0200
                Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-15 11:22 +1100
                  Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-15 02:48 +0200
                    Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-15 13:02 +1100
                Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 12:03 +1100
                  Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 09:12 +0200
                    Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-16 18:21 +1100
                      Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 09:40 +0200
                        Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 22:59 +1100
                    Re: generator/coroutine terminology Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-16 01:37 -0600
                      Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 09:52 +0200
                        Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 23:02 +1100
                          Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 14:42 +0200
                          Re: generator/coroutine terminology Jonas Wielicki <jonas@wielicki.name> - 2015-03-16 13:39 +0100
                    Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 19:36 +1100
                      Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-16 19:58 +1100
                        Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 22:51 +1100
                          Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-03-17 00:16 +1100
                      Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 14:32 +0200
                        Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 05:51 -0700
                          Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 15:13 +0200
                            Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 01:32 +1100
                              Re: generator/coroutine terminology Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-16 08:45 -0600
                          Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 00:39 +1100
                            Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 07:19 -0700
                              Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-16 14:26 +0000
                                Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 07:37 -0700
                                  Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 07:55 -0700
                                  Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-16 18:19 +0000
                                    Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 19:52 -0700
                                      Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 03:07 +0000
                                        Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 20:18 -0700
                                          Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 03:25 +0000
                                            Re: generator/coroutine terminology Rustom Mody <rustompmody@gmail.com> - 2015-03-16 20:33 -0700
                                              Re: generator/coroutine terminology Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 03:55 +0000
                                      Re: generator/coroutine terminology Mario Figueiredo <marfig@gmail.com> - 2015-03-17 04:22 +0100
                              Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 01:35 +1100
                                Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 01:36 +1100
                            Re: generator/coroutine terminology Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-16 08:52 -0600
                              Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 17:09 +0200
                                Re: generator/coroutine terminology Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-16 09:26 -0600
                                  Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-16 18:05 +0200
                  Re: generator/coroutine terminology albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-31 13:18 +0000
                    Re: generator/coroutine terminology Dave Angel <davea@davea.name> - 2015-03-31 09:38 -0400
                      Re: generator/coroutine terminology albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-31 15:03 +0000
                        Re: generator/coroutine terminology Chris Angelico <rosuav@gmail.com> - 2015-04-01 02:36 +1100
                    Re: generator/coroutine terminology Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-03 17:02 +1100
                      Re: generator/coroutine terminology albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-18 17:52 +0000
                    Re: generator/coroutine terminology Paul Rubin <no.email@nospam.invalid> - 2015-04-02 23:46 -0700
    Re: generator/coroutine terminology Terry Reedy <tjreedy@udel.edu> - 2015-03-12 16:11 -0400
      Re: generator/coroutine terminology Marko Rauhamaa <marko@pacujo.net> - 2015-03-12 22:22 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#87560

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 special case of an iterator.
> And you wrote the iterator with 'class'.
> And from python 2.2(?) classes are types.
>
> So I dont know what "comp science theoretic perspective" you are describing...
>
>  From mine:
>
> The generator
> def gen():
>    yield 1
>    yield 2
>
> is much closer to the list (ie data) [1,2]
> than to say
>
> def foo():
>    print 1
>    print 2
>
> The only difference is that the list memoizes the data whereas the generator doesn't.
>
> CLU perspective:
> The iterator for a collection of complex_numbers can be used interchangeably with that for an array of integers
> from https://en.wikipedia.org/wiki/CLU_%28programming_language%29
> [Note: CLU-iterator ≡ python-generator]
>
> Haskell perspective:
> Lists are by default lazy and memoized.
> IOW in Haskell: List ≡ Lazy list ≡ python generator + memoization
>
> Scheme perspective:
> Programmer can choose between normal and lazy lists.
> Lazy lists are just normal lists + delay/force where
> delay x ≡ lambda: x
> force x ≡ x()
>
> ======================
> 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 can certainly be cleaned up.
>

So write the patches to correct the docs, then raise the issue on the 
bug tracker to get the patches accepted.  IIRC for doc patches you don't 
even have to provide diff files against the rst files, plain text will 
do, the core devs will do the rest for you.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87564

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 can certainly be cleaned up.
> >
> 
> So write the patches to correct the docs, then raise the issue on the 
> bug tracker to get the patches accepted.  IIRC for doc patches you don't 
> even have to provide diff files against the rst files, plain text will 
> do, the core devs will do the rest for you.

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 potato(x):
  yield x+1

tomato = potato(3)

what shall we call potato and tomato.
I believe this thread clearly shows that the docs are confused and inconsistent.
Yet I dont see any consensus on what/how to classify tomato/potato.

Function -- trouble on one side
Generator -- trouble on another
Iterator -- trouble on third 
etc

¹ Grey areas excepted eg output of help(); inspect module etc

[toc] | [prev] | [next] | [standalone]

#87567

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 potato(x):
>   yield x+1
> 
> tomato = potato(3)
> 
> what shall we call potato and tomato.
> I believe this thread clearly shows that the docs are confused and inconsistent.
> Yet I dont see any consensus on what/how to classify tomato/potato.
> 
> Function -- trouble on one side
> Generator -- trouble on another
> Iterator -- trouble on third 
> etc

And portmanteaus like generator-function are really the worst issue of all

I gave the example of 'pineapple'.

Steven gave another dozen examples that according to him are all ok.
Combine them with his earlier:
> Hopefully it is clear from context what we actually mean. When in doubt, we
> should be explicit. 

So if there is no ambiguity
pineapple can be apple (or is it pine)?
butterfly can be butter
And of course mush is much better than mushroom!

If anything the last 15 years have shown that portmanteaus will be shortformed;
they will be shortformed randomly and inconsistently;
even in the official docs and implementation -- not to mention all over the net.

[toc] | [prev] | [next] | [standalone]

#87581

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]
>>> But the mess around the docs can certainly be cleaned up.
>>>
>>
>> So write the patches to correct the docs, then raise the issue on the
>> bug tracker to get the patches accepted.  IIRC for doc patches you don't
>> even have to provide diff files against the rst files, plain text will
>> do, the core devs will do the rest for you.
>
> 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 potato(x):
>    yield x+1
>
> tomato = potato(3)
>
> what shall we call potato and tomato.
> I believe this thread clearly shows that the docs are confused and inconsistent.
> Yet I dont see any consensus on what/how to classify tomato/potato.
>
> Function -- trouble on one side
> Generator -- trouble on another
> Iterator -- trouble on third
> etc
>
> ¹ Grey areas excepted eg output of help(); inspect module etc
>

So the docs are confused and inconsistent but in an open source 
community it's not *MY* responsibility to deal with it, somebody else can.

Making mountains out of mole hills is all I see in this entire thread.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87598

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 dont expect the def can be revoked now.
> >>> [As far as I am concerned its a minor wart]
> >>> But the mess around the docs can certainly be cleaned up.
> >>>
> >>
> >> So write the patches to correct the docs, then raise the issue on the
> >> bug tracker to get the patches accepted.  IIRC for doc patches you don't
> >> even have to provide diff files against the rst files, plain text will
> >> do, the core devs will do the rest for you.
> >
> > 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 potato(x):
> >    yield x+1
> >
> > tomato = potato(3)
> >
> > what shall we call potato and tomato.
> > I believe this thread clearly shows that the docs are confused and inconsistent.
> > Yet I dont see any consensus on what/how to classify tomato/potato.
> >
> > Function -- trouble on one side
> > Generator -- trouble on another
> > Iterator -- trouble on third
> > etc
> >
> > ¹ Grey areas excepted eg output of help(); inspect module etc
> >
> 
> So the docs are confused and inconsistent but in an open source 
> community it's not *MY* responsibility to deal with it, somebody else can.
> 
> Making mountains out of mole hills is all I see in this entire thread.

Ok... Lets see... What if any agreement is there on this.

To start with basic terminology. Given

> def potato(x):
>    yield x+1
>
> tomato = potato(3)
>
> What shall we call potato and tomato?

Steven suggested that potato can be called 'factory'
Not ideal, but way better than 'generator-function'.
Oscar does not like it.
No better/other suggestions (that we see here).

What next?

Ok Let me throw out a suggestion:
 - potato is a generator
 - tomato is a cursor.
Acceptable?

So much for terminological questions.
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.
Here are some questions.

1. Is the name generator appropriate for coroutine-generator?
The wikipedia-link that Steven posted suggests the other-way-round 'is-a'
relation: "a generator is a (semi)coroutine¹"
2. Can we say
   yield-statement ≡ generator
   yield-expression ≡ coroutine
   ?
   What of x = yield y
           x = yield x

  My (vaguest) impression is that 'yield' stops being the meaningful word
  for coroutine -- see footnote from Frederik Lundh in the 2001 thread

> suspend instead of yield, but that's me
--------------------
¹ Non-trivial terminological headache: Is this 'generator' in the old sense or new
sense?

[toc] | [prev] | [next] | [standalone]

#87603

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...
>>>>>
>>>>> 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 can certainly be cleaned up.
>>>>>
>>>>
>>>> So write the patches to correct the docs, then raise the issue on the
>>>> bug tracker to get the patches accepted.  IIRC for doc patches you don't
>>>> even have to provide diff files against the rst files, plain text will
>>>> do, the core devs will do the rest for you.
>>>
>>> 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 potato(x):
>>>     yield x+1
>>>
>>> tomato = potato(3)
>>>
>>> what shall we call potato and tomato.
>>> I believe this thread clearly shows that the docs are confused and inconsistent.
>>> Yet I dont see any consensus on what/how to classify tomato/potato.
>>>
>>> Function -- trouble on one side
>>> Generator -- trouble on another
>>> Iterator -- trouble on third
>>> etc
>>>
>>> ¹ Grey areas excepted eg output of help(); inspect module etc
>>>
>>
>> So the docs are confused and inconsistent but in an open source
>> community it's not *MY* responsibility to deal with it, somebody else can.
>>
>> Making mountains out of mole hills is all I see in this entire thread.
>
> Ok... Lets see... What if any agreement is there on this.
>
> To start with basic terminology. Given
>
>> def potato(x):
>>     yield x+1
>>
>> tomato = potato(3)
>>
>> What shall we call potato and tomato?
>
> Steven suggested that potato can be called 'factory'
> Not ideal, but way better than 'generator-function'.
> Oscar does not like it.
> No better/other suggestions (that we see here).
>
> What next?
>
> 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?  I couldn't care less what 
they are called in any other language.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87607

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?  I couldn't care less what 
> they are called in any other language.

Ok so lets see...
https://docs.python.org/3.4/tutorial/classes.html#generators
https://docs.python.org/3.4/glossary.html#term-generator

Are these consistent with (your notion of) python?
Maybe they are "any other language"?

[toc] | [prev] | [next] | [standalone]

#87609

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 complicate something that is so simple?  I couldn't care less what
>> they are called in any other language.
>
> Ok so lets see...
> https://docs.python.org/3.4/tutorial/classes.html#generators
> https://docs.python.org/3.4/glossary.html#term-generator
>
> Are these consistent with (your notion of) python?
> Maybe they are "any other language"?
>

I'll already suggested you write the patches and put them on the bug 
tracker.  If you can't be bothered please have the courtesy to stop 
bleating about it.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87612

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?
> >>>
> >>
> >> No.  In Python potato is a generator function, tomato is a generator.
> >> Why complicate something that is so simple?  I couldn't care less what
> >> they are called in any other language.
> >
> > Ok so lets see...
> > https://docs.python.org/3.4/tutorial/classes.html#generators
> > https://docs.python.org/3.4/glossary.html#term-generator
> >
> > Are these consistent with (your notion of) python?
> > Maybe they are "any other language"?
> >
> 
> I'll already suggested you write the patches and put them on the bug 
> tracker.  If you can't be bothered please have the courtesy to stop 
> bleating about it.

Here are two of your posts (within a couple of hours)

1. 
> So the docs are confused and inconsistent but in an open source
> community it's not *MY* responsibility to deal with it, somebody else can.
> Making mountains out of mole hills is all I see in this entire thread. 

2. 
> No.  In Python potato is a generator function, tomato is a generator.
> Why complicate something that is so simple?  I couldn't care less what
> they are called in any other language. 

I understand the first as saying: "Since something is wrong correct it; Dont bleat!"

The second is saying "Nothing is wrong!"

Please decide which side you belong

[toc] | [prev] | [next] | [standalone]

#87616

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
>>>>>     - tomato is a cursor.
>>>>> Acceptable?
>>>>>
>>>>
>>>> No.  In Python potato is a generator function, tomato is a generator.
>>>> Why complicate something that is so simple?  I couldn't care less what
>>>> they are called in any other language.
>>>
>>> Ok so lets see...
>>> https://docs.python.org/3.4/tutorial/classes.html#generators
>>> https://docs.python.org/3.4/glossary.html#term-generator
>>>
>>> Are these consistent with (your notion of) python?
>>> Maybe they are "any other language"?
>>>
>>
>> I'll already suggested you write the patches and put them on the bug
>> tracker.  If you can't be bothered please have the courtesy to stop
>> bleating about it.
>
> Here are two of your posts (within a couple of hours)
>
> 1.
>> So the docs are confused and inconsistent but in an open source
>> community it's not *MY* responsibility to deal with it, somebody else can.
>> Making mountains out of mole hills is all I see in this entire thread.
>
> 2.
>> No.  In Python potato is a generator function, tomato is a generator.
>> Why complicate something that is so simple?  I couldn't care less what
>> they are called in any other language.
>
> I understand the first as saying: "Since something is wrong correct it; Dont bleat!"

The first is saying that *YOU* are complaining that the docs are 
inconsistent but *YOU* won't do anything about it.

>
> The second is saying "Nothing is wrong!"
>

The second is saying that those are *MY* definitions that *I'M* 
perfectly happy with.

> Please decide which side you belong
>

The side which hopes you give up this now very tedious thread.  Mario's 
response a few minutes back summed things up perfectly.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87608

On Mon, 16 Mar 2015 19:52:59 -0700 (PDT), Rustom Mody
<rustompmody@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 terminology just becomes pedantic. And if
you cross it once more, you get into the realm of obfuscation.
Congratulations, I suppose! You managed to have reached that edge.

Seriously, you started this thread well. I even nodded to my screen
when many posts back you mentioned correct terminology was an
important aspect of any official spec.

But you just couldn't stop, could you? What you aren't realizing is
that your quest for the perfect set of terms is exactly what is
leading you into a confusing state, producing the opposite effect of
making things harder to understand, instead of easier.

Continue this thread if you must, but please never write a spec in
your life.

[toc] | [prev] | [next] | [standalone]

#87562

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 generator is a special case of an iterator.
> And you wrote the iterator with 'class'.
> And from python 2.2(?) classes are types.

Yes, but iterators aren't *classes*, they are instances.


> So I dont know what "comp science theoretic perspective" you are
> describing...

http://en.wikipedia.org/wiki/Generator_(computer_programming)

"A generator is very similar to a function that returns an array, in that a
generator has parameters, can be called, and generates a sequence of
values. However, instead of building an array containing all the values and
returning them all at once, a generator yields the values one at a time,
which requires less memory and allows the caller to get started processing
the first few values immediately. In short, a generator looks like a
function but behaves like an iterator."





-- 
Steven

[toc] | [prev] | [next] | [standalone]

#87563

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.
>> 
>> You just showed Marko a few posts back, that
>> A generator is a special case of an iterator.
>> And you wrote the iterator with 'class'.
>> And from python 2.2(?) classes are types.
> 
> Yes, but iterators aren't *classes*, they are instances.
> 
> 
>> So I dont know what "comp science theoretic perspective" you are
>> describing...
> 
> http://en.wikipedia.org/wiki/Generator_(computer_programming)
> 
> "A generator is very similar to a function that returns an array, in that
> a generator has parameters, can be called, and generates a sequence of
> values. However, instead of building an array containing all the values
> and returning them all at once, a generator yields the values one at a
> time, which requires less memory and allows the caller to get started
> processing the first few values immediately. In short, a generator looks
> like a function but behaves like an iterator."

Oops, itchy trigger finger... the next paragraph is even more important:

"Generators can be implemented in terms of more expressive control flow
constructs, such as coroutines or first-class continuations.[2] Generators,
also known as semicoroutines,[3] are a special case of (and weaker than)
coroutines, in that they always yield control back to the caller (when
passing a value back), rather than specifying a coroutine to jump to; see
comparison of coroutines with generators."



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#87566

On Mon, Mar 16, 2015 at 7:39 AM, Steven D'Aprano
<steve+comp.lang.python@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 stalwarts dont like the current state of affairs
>
> /s/dont/didn't/
>
> That's a fifteen year old thread, written before generators were introduced.
> Guido's intuition has been vindicated -- generators have proven to be a
> great and powerful feature, and the reuse of "def" for both generator
> functions and regular functions has turned out to be no more confusing in
> practice than the use of "def" for both functions and methods[1].
>
>
> The argument is that generator-producers (def-with-yield) are not like
> regular functions because calling the def-with-yield doesn't execute the
> code inside them. Given three objects:

There is another argument, which is that for functions and classes,
the descriptive keyword ("def" or "class") is the first thing you see when
reading the code. 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 is a case where practicality has won over purity.

[toc] | [prev] | [next] | [standalone]

#87568

Ian Kelly <ian.g.kelly@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 correct that
> this is a case where practicality has won over purity.

I don't think that's all that big of a deal even though I will readily
admit having stumbled on it early on. I removed the last "yield"
statement from a generator expecting it to keep on being a generator.
Thus, you have to do things like:

   def nothing():
       if False:
           yield None

The "pass" and "global" statements make me think it might be more
Pythonic to have separate syntax for the special case:

   def nothing():
       yield not


Marko

[toc] | [prev] | [next] | [standalone]

#87569

On Mon, Mar 16, 2015 at 9:09 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@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 correct that
>> this is a case where practicality has won over purity.
>
> I don't think that's all that big of a deal even though I will readily
> admit having stumbled on it early on. I removed the last "yield"
> statement from a generator expecting it to keep on being a generator.
> Thus, you have to do things like:
>
>    def nothing():
>        if False:
>            yield None
>
> The "pass" and "global" statements make me think it might be more
> Pythonic to have separate syntax for the special case:
>
>    def nothing():
>        yield not

My (limited) experience with asyncio is that it also makes this a bit
worse. I write a function intended to be a coroutine invoked from
coroutines using "yield from", and then I realize that it's not a
coroutine because it never uses "yield from" itself. 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.

[toc] | [prev] | [next] | [standalone]

#87571

Ian Kelly <ian.g.kelly@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 interlocking of coroutines
suggests you should be able to introduce a blocking state anywhere with
a "yield from" statement. To avoid the problem you mention, you'd then
have to give up direct function call altogether and yield from
everything under the sun:

     # Use the supercomputer over RPC -- or not!
     root = yield from my_math.sqrt(x)

It could be done, but it won't look like Python code anymore. It
probably won't look like a computer program anymore.


Marko

[toc] | [prev] | [next] | [standalone]

#88380

In article <55062bda$0$12998$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>Marko Rauhamaa wrote:
>
>> Chris Angelico <rosuav@gmail.com>:
>>
>>> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa <marko@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 as, well,
>>>> iterators?
>>>
>>> If you treat them all as iterators, then you're safe, because that's
>>> the lowest common denominator. But there are a number of other
>>> iterators that have more features, including files, generators, etc.
>>
>> 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__(self):
>        self.i = 0
>    def __next__(self):
>        self.i += 1
>        return self.i**2
>    def __iter__(self):
>        return self

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.
(I did experiment with Squares interactively. But I didn't get
further than creating a Squares object.)


>
>
>Here's the same thing written as a generator:
>
>def squares():
>    i = 1
>    while True:
>        yield i**2
>        i += 1
>
>
>Four lines, versus eight. The iterator version has a lot of boilerplate
>(although some of it, the two-line __iter__ method, could be eliminated if
>there was a standard Iterator builtin to inherit from).
>
>Here's a more complicated example:
>
>class Randoms:
>    def __init__(self):
>        self.finished = False
>    def __next__(self):
>        x = random.random()
>        if x > 0.5:
>            self.finished = True
>        if self.finished:
>            raise StopIteration
>        else:
>            return x
>    def __iter__(self):
>        return self
>
>
>def randoms():
>    x = random.random()
>    while x < 0.5:
>        yield x
>        x = random.random()
>
>
>Generators, as a rule, are significantly easier to write, understand, and
>debug. There's nothing they can do that can't be done with an iterator
>class, but the fiddly, unexciting bits related to halting and resuming and
>saving state are all handled for you, allowing you to concentrate on the
>behaviour you want, not the boilerplate.

This is illuminating. Thanks.

>
>--
>Steven

Groetjes Albert
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#88383

On 03/31/2015 09:18 AM, Albert van der Horst wrote:
> In article <55062bda$0$12998$c3e8da3$5496439d@news.astraweb.com>,
> Steven D'Aprano  <steve+comp.lang.python@pearwood.info> 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:
>>     def __init__(self):
>>         self.i = 0
>>     def __next__(self):
>>         self.i += 1
>>         return self.i**2
>>     def __iter__(self):
>>         return self
>
> 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.
> (I did experiment with Squares interactively. But I didn't get
> further than creating a Squares object.)
>

He did say it was an iterator.  So for a first try, write a for loop:

class Squares:
    def __init__(self):
        self.i = 0
    def __next__(self):
        self.i += 1
        return self.i**2
    def __iter__(self):
        return self

for i in Squares():
     print(i)
     if i > 50:
         break

print("done")


>
>>
>>
>> Here's the same thing written as a generator:
>>
>> def squares():
>>     i = 1
>>     while True:
>>         yield i**2
>>         i += 1
>>
>>
>> Four lines, versus eight. The iterator version has a lot of boilerplate
>> (although some of it, the two-line __iter__ method, could be eliminated if
>> there was a standard Iterator builtin to inherit from).
>>
-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#88387

In article <mailman.372.1427809109.10327.python-list@python.org>,
Dave Angel  <davea@davea.name> wrote:
>On 03/31/2015 09:18 AM, Albert van der Horst wrote:
>> In article <55062bda$0$12998$c3e8da3$5496439d@news.astraweb.com>,
>> Steven D'Aprano  <steve+comp.lang.python@pearwood.info> 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:
>>>     def __init__(self):
>>>         self.i = 0
>>>     def __next__(self):
>>>         self.i += 1
>>>         return self.i**2
>>>     def __iter__(self):
>>>         return self
>>
>> 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.
>> (I did experiment with Squares interactively. But I didn't get
>> further than creating a Squares object.)
>>
>
>He did say it was an iterator.  So for a first try, write a for loop:
>
>class Squares:
>    def __init__(self):
>        self.i = 0
>    def __next__(self):
>        self.i += 1
>        return self.i**2
>    def __iter__(self):
>        return self
>
>for i in Squares():
>     print(i)
>     if i > 50:
>         break
>

This is what I get:
/ --------------------------
albert@cherry:/tmp$ more aap.py
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:84292, Dec 26 2010, 22:31:48)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from aap import *
>>> for i in Squares():
...     print i
...     if i>50: break
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: instance has no next() method
>>>

/ --------------------------

Probably not what is intended.

Last minute note:
   renaming __next__() into next() did the job.

>--
>DaveA

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web