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

[Rustom Mody]

Will write the points later but for now...

On Sat, Apr 18, 2015 at 11:35 AM, Andrew Barnert  wrote:
> On Apr 17, 2015, at 21:48, Rustom Mody  wrote:
>>
>> On Sat, Apr 18, 2015 at 12:28 AM, Yury Selivanov
>>  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

Yes its this loose usage not just across the net but in the docs that
in my experience are giving a great deal of trouble to noobs.

Just to be clear: I am not talking about changing the language at
all¹; just streamlining the docs.
I believe we just should take the current way of def-ining generators
as a given.
Then the discussions can be more meaningful and less FUD-ly

I will write up a summary of that thread...
-----------------
¹ Well with the exception of areas where the line between semantics
and docs is hazy eg help() and introspection