Reasons for Python async/await • Hacker News Board

Re: Reasons for Python async/await

#51

Post by drothlis » Thu, May 21, 2015, 10:56 AM UTC

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?

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... [2] https://lwn.net/Articles/643786/

Re: Reasons for Python async/await

#52

Post by pandler » Thu, May 21, 2015, 11:25 AM UTC

munificent wrote: post #27

wtallis wrote: post #22

Earlier quoted context omitted.

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.

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

Re: Reasons for Python async/await

#53

Post by fruzz » Thu, May 21, 2015, 12:44 PM UTC

mherrmann wrote: post #47

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.

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.

Re: Reasons for Python async/await

#54

Post by pekk » Sat, May 23, 2015, 9:40 PM UTC

lqdc13 wrote: post #50

pekk wrote: post #45

Earlier quoted context omitted.

I'm curious. What is notably missing?

For me specifically, StatsModels, sklearn, REPL plotting (more of a language feature) with seaborn/matplotlib, scipy, various NLP libraries, pandas for parsing CSVs and fast vector operations on table-like data, an easy to use requests library (compared to http://golang.org/pkg/net/http/ ) and 10^6 C libraries that either someone already made bindings for or that you can easily make bindings for with Swig/boost (not…

Thanks, that helps me understand.

The problem for scientific users seems to be to achieve enough consensus about which language to use as an "obvious choice" that a bunch of other scientific users make packages.

Since we are talking about "fast" languages like Nim and Julia, I wonder why R and Python have done so well with the scientific audience but C++, Java, C# and the like never developed anything quite comparable. Or did they and I just didn't notice?