[Python-ideas] Generator/Coroutiine Ontology (was async/await in Python)

[Andrew Barnert]

On Apr 17, 2015, at 21:48, Rustom Mody <rustompmody at gmail.com> wrote:
> 
> On Sat, Apr 18, 2015 at 12:28 AM, Yury Selivanov
> <yselivanov.ml at gmail.com> wrote:
>> Hello python-ideas,
>> 
>> Here's my proposal to add async/await in Python.
>> 
>> I believe that PEPs 380 and 3156 were a major breakthrough for Python 3,
> 
> I am also interested in this topic --- from the other side.
> As a teacher of python it is my finding that the
> terminology/documentation around generators is rather chaotic and
> messy.
> Basically given:
> def foo():
>  yield 1
> bar = foo()
> 
> what do we call foo and what do we call bar?
> It is suggested that foo is "generator-function" and bar is "generator-object"
> Unfortunately python does not aid this distinction; witness
> 
>>>> def foo():
> ...  yield 1
> ...
>>>> bar = foo()
>>>> type(foo)
> <class 'function'>
>>>> type(bar)
> <class 'generator'>

I assume you're ok with the type(bar); the type of a generator object is named "generator", just like the type of a bound method object is named "method" and the type of an integer object is named "int", and so on.

So presumably you don't like the former. But what about it?

The only thing I can imagine is the fact that, even though a generator function is conceptually a "subkind" of function, there is no generator function subtype of the function type?

But so what? There's no closure function subtype, just functions whose closure is nonempty; there's no positive int subtype, just ints whose value is positive; etc. And likewise, there's no callable supertype that function and method (and other things) inherit.

If there were some additional API that a generator function should provide that other functions don't (or some implementation reason that makes it worth subclassing for convenience, I suppose), that would be a good reason for needing a subtype. For example, generator a subtype of iterator, just as file is, because they both add new methods that don't make sense for the base iterator type.

But just wanting repr(type(x)) to give you more information about x, that's not a good reason to add a subtype.

So, it seems to me like both of these are returning something you should reasonably expect.

Although you didn't bring this up here, I'll bet somewhere in that thread you point out that it's unfortunate that, in loose usage, people sometimes call a generator function--or, more often, the source code defining one--a generator, in the same way they sometimes call the source code defining a function a function, but there's ambiguity like that all over the natural language we use to talk about programming; as long as there are terms we can use when we need to be strict, it's rarely a problem. And I think we have such terms here: a generator function is the kind of function used to implement generator objects, while are a kind (and indeed a subtype) of iterator objects. Changing the strict names from the obvious ones to something that nobody can get wrong--like calling function definitions "code defs" so nobody loosely says "function" anymore--wouldn't be a win. Besides, the generator PEP and its discussion went over this in detail, and IIRC Guido's conclusion could be paraphrased as "I think this is FUD, but I don't think we'll be able to prove that except by looking at actual experience in a few years". In actual experience, I haven't seen anyone stumble over this except if they don't understand the basic generator abstraction at all. (I can't speak to whether that makes it harder to teach that abstraction to novices or not, but I would guess it only really affects the ones who are "reading ahead in class", who you can mostly count on to get things or ask good questions, because you can just avoid the loose usage entirely in class.)

> I asked about this on the python list
> http://code.activestate.com/lists/python-list/682286/
> 
> And it seems that many more dark corners emerged in the docs on this
> subject in that discussion.
> 
> Should I start a separate thread?
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/