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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#87424

On Sun, Mar 15, 2015 at 2:29 AM, Rustom Mody <rustompmody@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 get back a returned object. How is this
different from any other function? (Yes, by this definition a class
could be called an "object function". But the line is already somewhat
blurry; if I've read my history correctly, "int" used to be a
function, but now it's a type. A class is really just a special type
of factory function, just as a generator function is.)

ChrisA

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

#87425

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" 
> misleadingly suggests "apple that grows on pines"
> 
> A builtin function is a function in the builtin (or builtins -- can never remember) module
> A pure function is function that does not assign or mutate non-locals
> A Steven-function is a function that presumably Steven wrote 
> 
> However a "generator function" is a weird sort of function (at best).
> Not regarding it as a function is IMO more reasonable.

Another analogy somewhat closer home than pineapples.
In Pascal there are procedures and functions.
Even in the venerable Fortran there are subroutine-subprogram and (sub)function-subprogram.

C took the stupid approach of just throwing out one of these.
A decade of troubles was enough to convince people that it was needed and the
mysterious 'void-returning' function was introduced to simulate procedures

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 of which is to say that in retrospect we need (at least in imperative programming) procedures and functions.

Best if the language supports them

If not, then we need them all the more in the conceptual ontology we use to
build programs.

Analogously we need the generator 'design-pattern' as well as the function
design-pattern. Conflating one as a special case of the other is a recipe for
confusion

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

#87427

On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody <rustompmody@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 longjmp?
>
> All of which is to say that in retrospect we need (at least in imperative programming) procedures and functions.
>
> Best if the language supports them

Python has a broad concept of "functions/methods that return something
interesting" and "functions/methods that always return None". (The
distinction often corresponds to non-mutator and mutator methods, but
that's just convention.)

Pike has void and non-void functions, but you can sometimes trick the
system into giving you the return value of a void function. (Spoiler:
It'll be the integer 0.)

HTTP has some responses which contain no body (eg 304 NOT MODIFIED) as
well as many which do.

Ditto many other languages and protocols.

In each case, there's no _real_ distinction between functions and
procedures (Pike follows C in having "void functions", but they're
still functions), and I don't see any evidence indicating that this
has damaged the languages or protocols concerned - can you show
otherwise?

ChrisA

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

#87428

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 doesn't return anything!
> > Ah So a void function does a longjmp?
> >
> > All of which is to say that in retrospect we need (at least in imperative programming) procedures and functions.
> >
> > Best if the language supports them
> 
> Python has a broad concept of "functions/methods that return something
> interesting" and "functions/methods that always return None". (The
> distinction often corresponds to non-mutator and mutator methods, but
> that's just convention.)

With due respect Chris, you are confused:

Sure any effective *pythonista* (who writes useful python) will have this concept.

Python (as against pythonistas) has no such concept¹ as "function that ALWAYS
returns None"

Consider this foo

>>> def foo(x):
...  if x>0: return x-1
... 
>>> foo(3)
2
>>> foo(-1)
>>>

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.


----------------
Leaving aside latest type-annotation proposal.

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

#87429

On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody <rustompmody@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 support is actually needed? Look, I can write functions that
return values:

def square(x):
    return x*x

four = square(2)

and functions that don't:

def save_to_file(fn):
    with open(fn, "w") as f:
        f.write(stuff)
        f.write(more_stuff)

save_to_file("/tmp/asdf")

Who cares that the second one actually returns None and then ignores
that? It's not returning anything, it's not using the function return
value. This is, in effect, a procedure.

How is Python worse off for doing things this way rather than having a
true "function with no return value" or "procedure" concept?

ChrisA

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

#87434

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 distinguish them
> > Python has no clue about it.
> 
> But what support is actually needed? Look, I can write functions that
> return values:
> 
> def square(x):
>     return x*x
> 
> four = square(2)
> 
> and functions that don't:
> 
> def save_to_file(fn):
>     with open(fn, "w") as f:
>         f.write(stuff)
>         f.write(more_stuff)
> 
> save_to_file("/tmp/asdf")
> 
> Who cares that the second one actually returns None and then ignores
> that? It's not returning anything, it's not using the function return
> value. This is, in effect, a procedure.
> 
> How is Python worse off for doing things this way rather than having a
> true "function with no return value" or "procedure" concept?

Well...
We can talk about that... maybe in another thread...
My more pressing question is that when I try to read the explanations of
generators, my tongue gets stuck behind my ears. And I suspect the problem is 
with the terminology

My original question was quite genuine:
Thanks to Marko's collections from the docs and also Steven's
> That glossary entry is misleading, or at least incomplete, and it fails to
> match the way "generator" is used by actual Python programmers. 

I guess I can confirm that the docs are messy the concepts are confused
and we (teachers) have to do whatever we will with that state of affairs.

[I admit to even having (tried to) teach C++. But I would not try to repeat that
feat if I had a choice]

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

#87430

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-function return void??
>>> No a void function doesn't return anything!
>>> Ah So a void function does a longjmp?
>>>
>>> All of which is to say that in retrospect we need (at least in imperative programming) procedures and functions.
>>>
>>> Best if the language supports them
>>
>> Python has a broad concept of "functions/methods that return something
>> interesting" and "functions/methods that always return None". (The
>> distinction often corresponds to non-mutator and mutator methods, but
>> that's just convention.)
>
> With due respect Chris, you are confused:
>
> Sure any effective *pythonista* (who writes useful python) will have this concept.
>
> Python (as against pythonistas) has no such concept¹ as "function that ALWAYS
> returns None"
>
> Consider this foo
>
>>>> def foo(x):
> ...  if x>0: return x-1
> ...
>>>> foo(3)
> 2
>>>> foo(-1)
>>>>
>
> 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.
>

Python *ALWAYS* returns None for any path through a function that 
doesn't specify a return value.  Taking your example.

 >>> def foo(x):
...     if x>0: return x-1
...
 >>> import dis
 >>> dis.dis(foo)
   2           0 LOAD_FAST                0 (x)
               3 LOAD_CONST               1 (0)
               6 COMPARE_OP               4 (>)
               9 POP_JUMP_IF_FALSE       20
              12 LOAD_FAST                0 (x)
              15 LOAD_CONST               2 (1)
              18 BINARY_SUBTRACT
              19 RETURN_VALUE
         >>   20 LOAD_CONST               0 (None)
              23 RETURN_VALUE

-- 
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]

#87433

On 03/14/2015 12:51 PM, Chris Angelico wrote:
> On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody <rustompmody@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 support is actually needed? Look, I can write functions that
> return values:
>
> def square(x):
>      return x*x
>
> four = square(2)
>
> and functions that don't:
>
> def save_to_file(fn):
>      with open(fn, "w") as f:
>          f.write(stuff)
>          f.write(more_stuff)
>
> save_to_file("/tmp/asdf")
>
> Who cares that the second one actually returns None and then ignores
> that? It's not returning anything, it's not using the function return
> value. This is, in effect, a procedure.
>
> How is Python worse off for doing things this way rather than having a
> true "function with no return value" or "procedure" concept?
>

And in C (at least the 80x86 implementations that I used) returns a 
value from a void function as well.  The value is an undefined int 
value, whatever the AX (EAX) register happened to contain.  The check 
that you didn't use such a value is made at compile time.

Further, in the original C definition, if you didn't define a return 
value, it was assumed to be int. And if you didn't define the arguments, 
they were assumed to be right.  In the "C calling convention," the 
caller was responsible for popping off the arguments, since the called 
function didn't necessarily have a clue how many there were.  Then 
later, for "efficiency reasons," they came up with the "Pascal calling 
convention," where the callee popped the arguments.  It perhaps was 
related to the fact that the 80x86 instruction set had the "return N" 
instruction which decremented the call stack pointer an additional 
amount, at the same time as doing the return.

I think the Python convention is exactly right for its other 
characteristics.  No declarations, no distinction.

-- 
DaveA

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

#88378

In article <83d579c1-ab61-4a3d-a834-e65d28eace8a@googlegroups.com>,
Rustom Mody  <rustompmody@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 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 function in the builtin (or builtins -- can
>never remember) module
>> A pure function is function that does not assign or mutate non-locals
>> A Steven-function is a function that presumably Steven wrote
>>
>> However a "generator function" is a weird sort of function (at best).
>> Not regarding it as a function is IMO more reasonable.
>
>Another analogy somewhat closer home than pineapples.
>In Pascal there are procedures and functions.
>Even in the venerable Fortran there are subroutine-subprogram and
>(sub)function-subprogram.

The Algol 68 designers considered it a defect in the design.
They created a situation like in Python, where a "def"-thingy need
not return a value.

>
>C took the stupid approach of just throwing out one of these.
>A decade of troubles was enough to convince people that it was needed and the
>mysterious 'void-returning' function was introduced to simulate procedures

The mistake this was intended to fix, was the rule that by default a
function returns int in C.

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]

#87468

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 would be wrong. There's nothing objectionable or misleading
about "generator-function" meaning a function which returns generators.
English is very flexible like that, and compound nouns can be used in many
different ways:

* a greenhouse is not a house that happens to be green;

* a mushroom is not a room where people mush;

* a butterfly is not a fly made of butter;

* a swimming pool is not a pool which swims;

* but a flying squirrel is a squirrel which (almost) flies.

Where a compound noun is made of two nouns, the "important" one can appear
either at the beginning or the end:

* a printer cartridge is a type of cartridge, not a type of printer;

* but an attorney general is a type of attorney, not a type of general.


So there is nothing unusual about "generator-function" being a type of
function.


> A builtin function is a function in the builtin (or builtins -- can never
> remember) module A pure function is function that does not assign or
> mutate non-locals A Steven-function is a function that presumably Steven
> 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 can regard it as a kind of yoghurt, if you like, but it isn't one.


py> def g():
...     yield 1
...
py> from inspect import isfunction
py> isfunction(g)
True



-- 
Steven

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

#89130

On Friday, March 13, 2015 at 5:36:35 PM UTC+8, Marko Rauhamaa wrote:
> Rustom Mody <rustompmody@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 generators to close" I mean 'generator-instances'
> > ie at runtime
> >
> > When you say "expect both to close with return" you are talking of
> > program-texts ie the 'factory'
> >
> > [Or I am guilty of the same I am accusing python of]
> 
> Your 'factory' is a:
> 
>     generator
>         A function which returns an iterator.
>     <URL: https://docs.python.org/3/glossary.html>
> 
> Your 'generator-instance' is an:
> 
>     iterator
>         An object representing a stream of data.
>     <URL: https://docs.python.org/3/glossary.html>
> 
> I don't think you should read much into what str(obj) returns. It's not
> much more than a random printable some CPython coder has cooked up in
> the heat of the moment.
> 
> 
> Marko

Well, the functional that returns a function instance which can be used
as an interator  is also a function. 

Well, some might use terms in generics programming as described in the book by Gangs of 4. 

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

#87367

On Fri, Mar 13, 2015 at 8:12 PM, Rustom Mody <rustompmody@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 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 them to close with "return".
>
> Nice demo of the same confusing terminology we are talking about.
>
> When I say "expect generators to close" I mean 'generator-instances' ie at runtime
>
> When you say "expect both to close with return" you are talking of program-texts
> ie the 'factory'
>
> [Or I am guilty of the same I am accusing python of]

Well, if you're going to discuss the specifics of terminology, we'd
best figure out what "close" means :)

You spoke of generators closing "with" StopIteration. Does that mean
that, once a generator closes, it raises StopIteration? That's the job
of the next() method, in effect. Or do you mean that raising
StopIteration will terminate the generator? That won't be true
forever, and shouldn't be relied on - just use "return".

If you use the close() method, Python throws a GeneratorExit into your
generator. But unless you have something that catches that, you
shouldn't need to worry about it; all you need to know is that you
call close() and the function cleanly terminates. Like I said, there
are implementation details that don't usually matter.

ChrisA

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

#87448

On 12 March 2015 at 16:52, Rustom Mody <rustompmody@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 at type, g's type is 'generator' whereas foo is just plain-ol
>> > 'function.'
>> >
>> > Whereas in informal usage we say foo is a generator.
>>
>> Hopefully it is clear from context what we actually mean. When in doubt, we
>> should be explicit.
>
> There is a very important 'context' where both have to exist together -- teaching beginners.

It is definitely important to draw the distinction between a generator
function and a generator in teaching. I would use distinct terminology
in any case. It's also important where possible to use the same
terminology as is used in the various different sources of
documentation that your students will encounter so inventing a new
term like "generator factory" is probably a bad idea.

> foo's are written to produce g's. g's come from foo-like.
>
> Better naming would help clarify -- your 'factory' is the best Ive seen so far.

I dislike the term "generator factory". To me it suggests something
like foo below:

def baz():
    yield 4

def bar():
    yield 6
    yield 7

def foo(x):
    if x > 4:
        return baz()
    else:
        return bar()

The existing terminology seems fine to me: A generator function is a
special kind of function containing a yield statement that always
returns a generator. A generator expression is a special kind of
expression that evaluates to a generator. A generator is a special
type of iterator that results from generator functions and generator
expressions.

> But the docs?!?! Hoo Boy My head spins trying to grok this
> https://docs.python.org/3/reference/expressions.html#generator-expressions
> And thats after being familiar with the origins of the idea in
> scheme/simula/CLU etc.

Perhaps the docs can be improved. I wouldn't recommend that particular
page to anyone who wasn't already familiar with the subject though.


Oscar

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

#87451

Oscar Benjamin <oscar.j.benjamin@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 if the application just treated all iterators as, well, iterators?


Marko

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

#87453

On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Oscar Benjamin <oscar.j.benjamin@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 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.

ChrisA

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

#87457

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?


Marko

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

#87458

On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa <marko@pacujo.net> 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?

You can send values into them, throw exceptions into them, and close
them (which is a special case of the latter).

ChrisA

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

#87459

Chris Angelico <rosuav@gmail.com>:

> On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa <marko@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 latter).

Hm. I wonder why the distinction was made. IOW, why is

   iter([1, 2, 3])

not equivalent with

   (x for x in [1, 2, 3])

I can close the latter but not the former.

After all,

   yield from [1, 2, 3]

works all right.


Marko

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

#87462

On Sun, Mar 15, 2015 at 11:48 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa <marko@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 latter).
>
> Hm. I wonder why the distinction was made. IOW, why is
>
>    iter([1, 2, 3])
>
> not equivalent with
>
>    (x for x in [1, 2, 3])
>
> I can close the latter but not the former.

You don't need to close the former.

> After all,
>
>    yield from [1, 2, 3]
>
> works all right.

That's using it as an iterable, which is not quite the same as an
iterator. (Iterators are themselves iterable; iter(x) is x, for any
iterator.) What you're doing there is roughly equivalent to:

for x in [1, 2, 3]:
    yield x

but with a bunch of other simplifications and guarantees for edge
cases and things. So it's going to call iter() on what you give it.

If you treat things as iterators, you can use all sorts of things. You
don't need to distinguish the different types. The distinction is
important if you want to do more than just iterate over something.

>>> def gather():
    lst = []
    try:
      while True:
        lst.append((yield len(lst)))
    except StopIteration:
      yield lst

>>> n = gather()
>>> next(n)
0
>>> n.send("Hello")
1
>>> n.send("World")
2
>>> n.throw(StopIteration)
['Hello', 'World']

You can't do that with a simple iterator. (Not that I'm saying this is
good design...)

ChrisA

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

#87500

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


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.



-- 
Steven

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

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

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

csiph-web