Reasons for Python async/await • Hacker News Board

Re: Reasons for Python async/await

#41

Post by tmc2 » Thu, May 21, 2015, 4:14 AM UTC

coldtea wrote: post #38

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

Mainstream is not a "moving goalpost fallacy". It was stated from the starting comment that he was talking about a "mainstream" language. Of course the "mainstreamity" of languages is hard to determine, but Dart is so low in any kind of related metric that makes this a non-issue. Let's put it this way: the Dart team announced a few months ago that they'd be concentrating on transpiling [1] and they won't put the VM o…

> nobody gave much of a fuck

I don't at all mind your saying so, but it might be frowned on around here.

> Mainstream is not a "moving goalpost fallacy".

Why can't you read?

Re: Reasons for Python async/await

#42

Post by laurencerowe » Thu, May 21, 2015, 4:27 AM UTC

BuckRogers wrote: post #39

laurencerowe wrote: post #35

Earlier quoted context omitted.

The majority popular Python libraries have gone the polyglot route of supporting both Python 2 and Python 3 from the same codebase, so its really not accurate to characterize Python folks as two separate communities.

Two problems with this. There is a very long tail of libraries on 2.x only that are not moving to 3. Second problem is that many 3.x only libraries are not widely used or tested and you'll find obvious errors that would not be there if they were widely used. And as you said, some popular libs are 2/3 compatible. So what should an end user do? Build on 3, which still has many things missing and less reliable 3.x libra…

When I started my current project two and half years ago I stuck with Python 2 because I was concerned about library support even though the major libraries I was using (Pyramid and SQLAlchemy) already supported Python 3.

While I think that was the right decision at the time, for me the balance shifted about 6 months. Needing access to the much improved multiprocessing library in Python 3 I ported my application to polyglot with the help of the python-future library. It really wasn't very difficult.

This was a modern codebase of about 20K LOC with reasonably high test coverage. For much larger or older applications then not porting is probably the right choice. But for new applications I think Python 3 is a fairly good bet now. Even if only 15-20% of the Python ecosystem have switched then that's still a significant enough userbase for most libraries to have had their Python 3 bugs shaken out.

Re: Reasons for Python async/await

#43

Post by pekk » Thu, May 21, 2015, 4:32 AM UTC

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

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

Re: Reasons for Python async/await

#44

Post by pekk » Thu, May 21, 2015, 4:33 AM UTC

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

You're right about asyncio, but the new async PEP undeniably adds a lot of complication to a story which was already working.

Re: Reasons for Python async/await

#45

Post by pekk » Thu, May 21, 2015, 4:34 AM UTC

lqdc13 wrote: post #19

BuckRogers wrote: post #14

Earlier quoted context omitted.

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.

I'm curious. What is notably missing?

Re: Reasons for Python async/await

#46

Post by semi-extrinsic » Thu, May 21, 2015, 5:59 AM UTC

BuckRogers wrote: post #31

semi-extrinsic wrote: post #29

Earlier quoted context omitted.

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.

The issue isn't porting, it's testing. I work in one of the largest Python shops in the United States. We don't have 100% test coverage (I don't know anyone who does). So there will be stuff breaking. With hundreds of thousands of lines of Python code, the testing/fixing burden would be enormous. It just doesn't make business sense to move. This codebase will never be on Python3. And I think it would be a serious mis…

You know you can add a few "from __future__ import X" statements and start writing Python3 in your codebase today? That way you can at least take advantage of new language features.

Re: Reasons for Python async/await

#47

Post by mherrmann » Thu, May 21, 2015, 7:37 AM UTC

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.

Re: Reasons for Python async/await

#48

Post by anonymoushn » Thu, May 21, 2015, 7:48 AM UTC

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

Lua has a more general thing that is maybe comparable to Greenlet. Maybe it's not mainstream or not exactly the same feature though.

Re: Reasons for Python async/await

#49

Post by rat87 » Thu, May 21, 2015, 9:23 AM UTC

cbsmith wrote: post #24

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

I think that's wrong,

    def lazy_lines(filename):
        with open(filename) as f:
            for line in f:
                yield f

works just fine

Re: Reasons for Python async/await

#50

Post by lqdc13 » Thu, May 21, 2015, 10:17 AM UTC

pekk wrote: post #45

lqdc13 wrote: post #19

Earlier quoted context omitted.

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

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 sure if it's as easy with Go).

Not to mention, all the "convenience" libs that are easy to implement but would take forever to make them all yourself. Examples like jaro distance, jaro-winkel distance, etc.

Unrelatedly, I wish Nim was more popular and I wish they concentrated on math more. Having a general purpose fast language that you can prototype in is amazing. Although you can't really blame such a small community for not focusing on a niche.

Julia might be great eventually, and it's really fun to write in and much easier to implement new things in compared to Cython, but not so great right now for my purposes. You end up importing the Julia library from Python and it takes a month to JIT compile some things. Also, string processing is not nearly as easy as it is in Python.