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