3 ms·
Here is my take on it. A Python generator is a lazily computed, readable stream. Generators have been integrated very nicely with the rest of the language (the
by ggchappell 12y ago
Here is my take on it.
A Python generator is a lazily computed, readable stream. Generators have been integrated very nicely with the rest of the language (the iterator protocol, for loops, etc.). The result is that Python now has excellent support for the style of programming that builds a system out of composable components.
It is almost incidental that a generator function is really a kind of coroutine. This fact does make them very convenient to write; but when generators were designed, I don't think anyone was saying, "Let's add a high-quality coroutine facility to Python."
But somewhere along the way, someone noticed that generators are coroutines. If you don't mind doing a "yield" whenever a coroutine needs to give up control -- possibly using a bit of twisted syntax to make that work -- generators are in fact coroutines in full generality.
But they don't look that way. If you just want to pass around control and do things asynchronously, you are still required to use the send-this-value-out-on-the-stream syntax. Conceptually, this is not the right abstraction. It is also occasionally cumbersome; wrapping a code snippet in some asynchronous processing is messy, for example.
That, plus the fact that the async/await (or future/promise) idea has proven itself to be effective and useful in other languages, suggests that Python needs additional constructions for doing coroutines.
That being said, I'm a bit leery of this PEP myself. The Rationale and Goals section, posted by ceronman, is all about deficiencies in the syntax. The real problem is that Python syntax is not sufficiently versatile to allow a programmer to create needed abstractions. We're talking about adding two new keywords and several constructions to support abstractions whose functionality can be implemented currently in Python, but cannot be given a nice interface.
I would prefer it if attention were given to the kind of syntax Python allows for programmer-created abstractions. Give me enough power that I can write async & await myself, along with some other things I might come up with, but which no one else has thought of yet. Polished versions of async/await can then be added to the standard library.
- sametmax 12y agoYour last paragraph makes sense indeed.