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

11–20 of 54 posts

Re: Reasons for Python async/await

#11

Post by skybrian »

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'…

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

Re: Reasons for Python async/await

#12

Post by tmc2 »

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'…

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

Hi. https://www.dartlang.org/articles/beyond-async/

Re: Reasons for Python async/await

#13

Post by Rapzid »

kbar13 wrote: post #6
avolcano wrote: post #5

Earlier quoted context omitted.

I 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."

to be fair python3 is a pretty large distribution (by filesize and features), and it requires having the python interpreter to run code.

And a minimal working mono distro is pretty small.

Re: Reasons for Python async/await

#14

Post by BuckRogers »

abecedarius wrote: post #10
wldcordeiro wrote: post #9

Earlier quoted context omitted.

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

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

Re: Reasons for Python async/await

#15

Post by [deleted] »

tmc2 wrote: post #12
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'…

> the first mainstream imperative scripting language to have these async/await concepts built-in Hi. https://www.dartlang.org/articles/beyond-async/

[deleted]

Re: Reasons for Python async/await

#16

Post by cwyers »

tmc2 wrote: post #12
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'…

> the first mainstream imperative scripting language to have these async/await concepts built-in Hi. https://www.dartlang.org/articles/beyond-async/

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

Re: Reasons for Python async/await

#17

Post by jacobolus »

abecedarius wrote: post #10
wldcordeiro wrote: post #9

Earlier quoted context omitted.

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

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. (Not to mention Stackless, etc.)

These will all continue to work going forward, but they will now be interoperable and based on a common foundation which is solidly implemented and included in the standard library. Everyone wins.

Re: Reasons for Python async/await

#18

Post by tmc2 »

cwyers wrote: post #16
tmc2 wrote: post #12

Earlier quoted context omitted.

> the first mainstream imperative scripting language to have these async/await concepts built-in Hi. https://www.dartlang.org/articles/beyond-async/

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

Re: Reasons for Python async/await

#19

Post by lqdc13 »

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…

Go unfortunately doesn't have all the awesome Python libs.

Re: Reasons for Python async/await

#20

Post by nostrademons »

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

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 generators - all of these can be implemented as add-on libraries and have been in at least one language, but we've found that this results in chaos in the language ecosystem. Similarly, protocol parsers, web frameworks, ORMs, command-line utilities (readline/curses, not argparsing), GUI frameworks - all of these have been wrapped into the stdlib of some library or other, but we've found that they aren't essential, and are often better off as a third-party package.

The one feature that IMHO should get baked into a language but nobody's done right yet is API versioning. Wish more people paid attention to the evolution of a program over time rather than a snapshot of where it is now.

Post reply on HN