Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons for Python async/await

lwn.net

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Reasons for Python async/await

#21

Post by milroc »

avolcano wrote: post #2

For context on this, check out PEP 492: 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'…

hack (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).

Re: Reasons for Python async/await

#22

Post by wtallis »

tmc2 wrote: post #18
cwyers wrote: post #16

Earlier quoted context omitted.

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

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.)

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

Re: Reasons for Python async/await

#23

Post by 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?

Re: Reasons for Python async/await

#24

Post by 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.

Re: Reasons for Python async/await

#25

Post by rmtew »

jacobolus wrote: post #17
abecedarius wrote: post #10

Earlier quoted context omitted.

Counterpoint: 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.

Nah, asyncio (including both the library and these new language features) is a huge simplification of the ecosystem for people writing network code, while people not writing asynchronous code can pretty much ignore it if they want to. Currently there’s a large split between folks programming against Twisted, Tornado, Eventlet/Gevent, rolling their own thing, or just writing blocking code and getting crap performance.…

> ..., while people not writing asynchronous code can pretty much ignore it if they want to.

I don't think this is strictly true. If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa.

This is something I've found to be a problem in C#. Specifically, trying to use Microsoft async only API from sync code. And that async API really requires the whole stack to be async, so using the APIs from sync code requires hacks found at Stackoverflow.

It's a split in the code base, and extra work and complication for developers. I'm not saying that it's not worth it, or it shouldn't go in.

Re: Reasons for Python async/await

#26

Post by jacobolus »

rmtew wrote: post #25
jacobolus wrote: post #17

Earlier quoted context omitted.

Nah, asyncio (including both the library and these new language features) is a huge simplification of the ecosystem for people writing network code, while people not writing asynchronous code can pretty much ignore it if they want to. Currently there’s a large split between folks programming against Twisted, Tornado, Eventlet/Gevent, rolling their own thing, or just writing blocking code and getting crap performance.…

> ..., while people not writing asynchronous code can pretty much ignore it if they want to. I don't think this is strictly true. If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa. This is something I've found to be a problem in C#. Specifically, trying to use Microsoft async only API from sync code. And tha…

> If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa. [...] It's a split in the code base, and extra work and complication for developers.

This is already the case today. As I pointed out, there is currently a split into about 4–5 (at least) mutually incompatible versions of I/O and network protocol related code. The new features should cut that down to 2–3, which are easier to understand and reason about, to boot.

When I say people can ignore the changes, what I really mean is: to the extent they can ignore the complexities of syntax and semantics around asynchronous code today, they can continue to do so in the future.

Alternately, having language support and a solid built-in library might encourage some people to write their code using asynchronous rather than blocking I/O, without too terribly difficult a learning curve or too much mental overhead from the new abstractions.

Re: Reasons for Python async/await

#27

Post by munificent »

wtallis wrote: post #22
tmc2 wrote: post #18

Earlier quoted context omitted.

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.)

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

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.

Re: Reasons for Python async/await

#28

Post by DannoHung »

nostrademons wrote: post #20
jacobolus wrote: post #17

Earlier quoted context omitted.

Nah, asyncio (including both the library and these new language features) is a huge simplification of the ecosystem for people writing network code, while people not writing asynchronous code can pretty much ignore it if they want to. Currently there’s a large split between folks programming against Twisted, Tornado, Eventlet/Gevent, rolling their own thing, or just writing blocking code and getting crap performance.…

It's interesting how over the past several decades we've learned a lot about which features should be part of a language's standard distribution and which can be farmed off to third-party libraries. String types, standard data structures, package managers, concurrency/async features, type systems, object models, date formats, command-line parsing, log libraries, parsers for the language itself, documentation generato…

Well, you're talking about things where time and experience has more or less found that having everything in a language working the same exact way makes for huge productivity gains and in most cases it's easy to escape hatch out if you really need special behavior, but most of the time you don't versus things where almost no one wants to use the same shit.

Re: Reasons for Python async/await

#29

Post by semi-extrinsic »

BuckRogers wrote: post #14
abecedarius wrote: post #10

Earlier quoted context omitted.

Counterpoint: 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.

What 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 fro…

I believe 2.7 will be supported until 2020, and RedHat has indicated they might support it until 2027.

Having said that, porting your stuff to Python 3 isn't that bad. The automatic conversion tools get you 99.5% of the way, unless you're doing really crazy stuff.

Re: Reasons for Python async/await

#30

Post by ploxiln »

thristian wrote: post #23

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?

There'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
Post reply on HN