It's a really exciting proposal. AFAIK, it'd make Python 3 the first mainstream imperative scripting language to have these async/await concepts built-in (there is a similar proposal for JavaScript/ES7 built on top of generators and promises[1]). While I've commented before about how asyncio is still a bit more nascent than I'd like, I'm really excited to see where the community takes it.
Still, nice that Python will have it.
Seriously, why does it matter? Is Python 3 really a "scripting language"? I don't think so. It's fairly close to, for example, C#, that has had these particular concepts for a while now. As have many other languages. Again, I don't think it matters that much who was "first".
def my_generator():
with something() as bar:
for x in baz():
yield bar(x) # context manager will call bar.__exit__() before the second time through this loop.
It'd make a LOT more sense to just make "with" understand when it is in a continuation and only invoke __exit__() when the continuation is being destroyed. Python 3.4.2 (default, Dec 23 2014, 17:01:26)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from contextlib import contextmanager
>>> @contextmanager
... def printme():
... print('enter')
... yield
... print('exit')
...
>>> def my_generator():
... with printme():
... for x in range(3):
... yield x
...
>>> for x in my_generator():
... print(x)
...
enter
0
1
2
exit def lazy_lines(filename):
with open(filename) as f:
for line in f:
yield f
works just fineGiven how closely tied generators are with async/await, why do we need "async def"? Isn't the presence of "await" or "async for" or "async with" enough to mark a function as asynchronous?
See the PEP's "rationale and goals"[1] and this article[2] summarising the PEP.
[1] https://www.python.org/dev/peps/pep-0492/#rationale-and-goal... [2] https://lwn.net/Articles/643786/
The Python 2/3 divide isn't that big of a deal anymore. This is not 2010. Almost all of the important libraries support Python 3; thinking especially to scientific computing. More and more distros are offering Python 3 by default. Big projects, like Red Hat's package manager, have switched to Python 3 (in Yum's case, by its replacement DNF).
It's only a matter of time before Python 2 isn't something that will be encountered in mainstream projects, only legacy systems. Which is nothing new (there's still lots of Fortran projects out there.) For them, the old version still exists. It will always exist. Should they want to make the jump to Python 3, the resources required are much less as compared to making the jump to another language.
Python 3 fixes fundamental flaws collected over the first twenty years of its inception. For those that cannot use a newer version of the language at this time, the old version is available.
This is the ACM Queue paper about async/await in Dart (iirc according to Erik Meijer the cleanest implementation of the concept so far).