

Reasons for Python async/await - hittaruki
https://lwn.net/Articles/644128/

======
avolcano
For context on this, check out PEP 492:
[https://www.python.org/dev/peps/pep-0492/](https://www.python.org/dev/peps/pep-0492/)

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.

[1]: [https://github.com/lukehoban/ecmascript-
asyncawait](https://github.com/lukehoban/ecmascript-asyncawait)

~~~
tmc2
> the first mainstream imperative scripting language to have these async/await
> concepts built-in

Hi. [https://www.dartlang.org/articles/beyond-
async/](https://www.dartlang.org/articles/beyond-async/)

~~~
cwyers
I don't know that the definitional argument is worth having, but Python is
more mainstream than Dart by a good deal.

~~~
tmc2
I didn't realize factual corrections need to be cleared by a committee that
decides which languages matter.

("More mainstream" is a moving goalpost fallacy.)

~~~
wtallis
Would you care to propose an objective criterion by which Dart is within an
order of magnitude of the popularity or prevalence of Python?

~~~
munificent
That depends on if you define "mainstream" to mean "lots of users" or "similar
to the kinds of things with lots of users".

If I write songs that sound like Taylor Swift but no one knows who I am, do I
make "mainstream" music? Personally, I would say yes.

~~~
pandler
> If I write songs that sound like Taylor Swift but no one knows who I am, do
> I make "mainstream" music? Personally, I would say yes.

You might make mainstream music but you yourself are not mainstream.

------
tosh
Related:
[http://queue.acm.org/detail.cfm?ref=rss&id=2747873](http://queue.acm.org/detail.cfm?ref=rss&id=2747873)

This is the ACM Queue paper about async/await in Dart (iirc according to Erik
Meijer the cleanest implementation of the concept so far).

------
cbsmith
The problem I have with async with is that you've already got issues with the
syntax for "with" context managers and generators.

    
    
        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.

~~~
laurencerowe
Are you sure? I only see __exit__() being called after the loop:

    
    
        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

------
mherrmann
It seems to me like this is a feature that will only be used by 1% of Python
programmers. I'm lacking a lot of context but personally I'd much prefer it if
Guido spent his time fixing the Python 2/3 conundrum. And even though these
proposed changes are Python 3 only, the fact that only so few people will use
them doesn't do much in that regard.

~~~
fruzz
I feel that concurrency is something used by far more than 1% of programmers.
That it will be built-in the language itself, rather than through libraries,
is pretty important in terms of delivering simpler code.

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.

------
thristian
The nice thing about Python generator functions was that they didn't need a
lot of syntax - if a function contains the "yield" keyword, it's a generator,
otherwise it's not.

Given 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?

~~~
drothlis
A major motivation for the new syntax is to support refactoring (currently
moving "yield" into a sub-function makes the calling function no longer a
generator).

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...](https://www.python.org/dev/peps/pep-0492/#rationale-and-goals) [2]
[https://lwn.net/Articles/643786/](https://lwn.net/Articles/643786/)

