8 ms·
Reasons for Python async/await
- avolcano 11y agoFor 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
- kyberias 11y agoIt would also make it the first programming language that starts with the letter P and ends with letter N to have those concepts. 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".
- avolcano 11y agoI don't think it matters who's first either; I'm just excited that Python's one of the first languages to implement these concepts beyond C#. Only used the term "scripting language" as a way to say "lighter-weight."
- kbar13 11y agoto be fair python3 is a pretty large distribution (by filesize and features), and it requires having the python interpreter to run code.
- Rapzid 11y agoAnd a minimal working mono distro is pretty small.
- balls187 11y agoI don' think you're making your point effectively. "It's exciting that Python is embracing these features." That's really what you're trying to hit home.
- wldcordeiro 11y agoAn exciting thing that's happening here is that this adds another thing to Python 3 that is enticing to developers. There's been a lot of great improvements to the language in the 3.x line and the more things to lure people away from 2.x the better.
- abecedarius 11y agoCounterpoint: I'm already uneasy about how complex the language has gotten. I like asyncio in principle, but here we see that addition spawning another addition.
- BuckRogers 11y agoWhat other option do they have to try to draw people over to Python3 that isn't a lot of work? I agree though. It's a kitchen sink rather than a smartly designed, concise language. I like to keep up on goings-on, but I work in a Python2 shop, I don't foresee myself or our business ever using Python3. While I love Python2, my Python3 will be Go. I like that Go is not a kitchen-sink language. I've also learned more from it, and I believe it adds more to my skillset and resume than Python3 ever will. That's my plan at least, to stop using Go just for fun, stop using Python for daily work, and use Go for fun and daily work. That's when the time comes that Python2 is no longer relevant and doesn't have the library support it enjoys today. I expect 2.7 library support to last a very long time.
- lqdc13 11y agoGo unfortunately doesn't have all the awesome Python libs.
- BuckRogers 11y agoThis is true, but hopefully by the time Python library maintainers drop 2.7 support, the Go space will be more than ready. Should be plenty of time for that to happen. There's probably a few decades of 2.7 library support, given the stats I've seen show 3.x at 10-17% of the userbase. Even if that doubles in 5 years (won't happen), it'll still be ~34% on Python3. Which is so long from the 2008 Python3 launch date, and a small enough number migrating that we can effectively concede these are two separate communities going forward.
- skybrian 11y agoDart has async/await. I'm not sure if it counts as mainstream, but it's well-known and it's an imperative scripting language. Still, nice that Python will have it.
- tmc2 11y ago> 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/
- deleted 11y ago[deleted]
- cwyers 11y agoI don't know that the definitional argument is worth having, but Python is more mainstream than Dart by a good deal.
- tmc2 11y agoI 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 11y agoWould you care to propose an objective criterion by which Dart is within an order of magnitude of the popularity or prevalence of Python?
- munificent 11y agoThat 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 11y ago> 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.
- milroc 11y agohack (PHP by Facebook) has it. Though not mainstream. Also some companies have forked python to support coroutines themselves (http://ironport.github.io/shrapnel/index.html http://ironport.github.io/shrapnel/index.html).
- pekk 11y agoWhat is the point of the community taking this anywhere when it is likely to be superseded by something else soon? It wasn't really that long ago that we got the original coroutines PEP and "yield from," now they are being obsoleted in favor of something that isn't clearly better.
- anonymoushn 11y agoLua has a more general thing that is maybe comparable to Greenlet. Maybe it's not mainstream or not exactly the same feature though.
- deleted 11y ago[deleted]
- tosh 11y agoRelated: 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).
- thristian 11y agoThe 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?
- ploxiln 11y agoThere's already a decorator @asyncio.coroutine which "async def" replaces. It's used for error checking, but also for some functions which are coroutines but don't use "yield" - they just return a Future
- drothlis 11y agoA 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-goals https://www.python.org/dev/peps/pep-0492/#rationale-and-goal... [2] https://lwn.net/Articles/643786/ https://lwn.net/Articles/643786/
- cbsmith 11y agoThe 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 11y agoAre 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
- rat87 11y agoI think that's wrong, def lazy_lines(filename): with open(filename) as f: for line in f: yield f works just fine
- mherrmann 11y agoIt 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 11y agoI 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.