Reasons for Python async/await • Hacker News Board

Re: Reasons for Python async/await

#31

Post by BuckRogers » Thu, May 21, 2015, 12:50 AM UTC

semi-extrinsic wrote: post #29

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…

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 mistake even if it could be done, as the Python3 "migration" isn't done, until it's actually happened. Right now the numbers I've seen are that 10-20% of the Python userbase is on 3.x. The future for Python3 is sketchy at best, those support dates are nothing more than political propaganda. If they meant something, they wouldn't have already pushed it back to 2020. Even if it did matter, code doesn't just stop working when the ball drops in 2020.

So if I could snap my fingers and port us over to 3, and have no breakage (which would cost us millions if not sink the entire business)- I still wouldn't do it. The best strategy is keep on using Python2, which with ~80% of the userbase still at this point in 2015. Python 3.0 was released late 2008. It would be a mistake to switch even if it were risk-free.

We will be using Python2, and bringing Go in-house for new components where we would have used Python3 in an alternate universe where the migration wasn't botched by the CPython core dev team.

Re: Reasons for Python async/await

#32

Post by tmc2 » Thu, May 21, 2015, 1:01 AM UTC

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's a loaded question, in that it's notoriously difficult to measure, and you already know the answer, but here:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

Surprised?

Re: Reasons for Python async/await

#33

Post by BuckRogers » Thu, May 21, 2015, 1:33 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.

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

Re: Reasons for Python async/await

#34

Post by 1st1 » Thu, May 21, 2015, 2:21 AM UTC

BuckRogers wrote: post #33

lqdc13 wrote: post #19

Earlier quoted context omitted.

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

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

Stop spreading FUD please.

Re: Reasons for Python async/await

#35

Post by laurencerowe » Thu, May 21, 2015, 2:47 AM UTC

BuckRogers wrote: post #33

lqdc13 wrote: post #19

Earlier quoted context omitted.

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

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

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.

Re: Reasons for Python async/await

#36

Post by laurencerowe » Thu, May 21, 2015, 2:52 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…

Are 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

Re: Reasons for Python async/await

#37

Post by coldtea » Thu, May 21, 2015, 3:45 AM UTC

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/

Missed the "mainstream" part.

Dart is hardly used by anyone.

Re: Reasons for Python async/await

#38

Post by coldtea » Thu, May 21, 2015, 3:48 AM UTC

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

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 officially in Chrome, and nobody gave much of a fuck judging from reactions in blogs, forums, HN etc.

If a mainstream language changed something, even something minor, there would have been blood (as it often happens).

[1] http://www.infoworld.com/article/2902074/javascript/google-d...

Re: Reasons for Python async/await

#39

Post by BuckRogers » Thu, May 21, 2015, 3:50 AM UTC

laurencerowe wrote: post #35

BuckRogers wrote: post #33

Earlier quoted context omitted.

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

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 libraries? Or stick with 2 which has everything the 3-only ecosystem has and much more. 3.x in reality makes no sense unless you have a political bone to pick. The big attraction was the unicode by default.

Python has supported unicode since 2.6. Python3 presents a new default way of handling it, nothing more. Py3 is pure technical churn at its worst. There's no innovation there. As a result the users outside of a vocal minority aren't coming.

Re: Reasons for Python async/await

#40

Post by coldtea » Thu, May 21, 2015, 3:52 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.

Or features, including very basic ones.

Go mostly adds a lot of busywork for exchange of a speed bump (that you could get with another decent language with types, like D or Nim, if only they weren't unpopular).

Nothing about Go makes someone a better programmer the way learning C or Lisp or Haskell does.