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

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

Post reply on HN
Print view View original

81–90 of 355 posts

Re: Why Is the Migration to Python 3 Taking So Long?

#81

Post by recursivecaveat »

The simple reason is that there was no compelling feature to reward you for upgrading. You'd spend a tremendous amount of effort for dubious return and (until recently) a smaller ecosystem.

1. Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.

2. Minor nice-to-haves like print-function, float division, and lazy ranges just hide landmines in the conversion while providing minimal benefit.

In the latest py3 versions we've finally gotten some sugar to tempt people over: asyncio, f-strings, dataclasses, and type annotations. Still not exactly compelling, but at least something to encourage the average Joe to put in all the effort.

Re: Why Is the Migration to Python 3 Taking So Long?

#82

Post by KaiserPro »

I now work on a python 3.6 codebase. Something like 100k lines of code. in practice 80% of the code was written for 3.5.

However, barring speed improvements, there isn't much to offer, apart from unicode, f strings and annotations.

If python 3 had proper multithreading, that might have been worth breaking backwards compatibility for.

Re: Why Is the Migration to Python 3 Taking So Long?

#83

Post by smacktoward »

sweeneyrod wrote: post #72
erokar wrote: post #36

Earlier quoted context omitted.

The nuisance of having to add self as parameter to every class method, no way of enforcing private methods and the mix between methods on objects and functions in the standard library. OO feels more integrated in e.g. Ruby. About some of the design decisions in Guido's own words: http://python-history.blogspot.com/2009/02/adding-support-fo...

The first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.

There's a fine line between "explicit is good because it means how things behave is obvious" and "explicit is bad because it means typing the same boilerplate over and over again."

Not saying Python fell on the wrong side of that line, just that it's an easy line to end up on the wrong side of.

Re: Why Is the Migration to Python 3 Taking So Long?

#84

Post by pmiller2 »

privateSFacct wrote: post #40
hermod wrote: post #23

Earlier quoted context omitted.

With respect to async, I'm partial to trio [0], which is a spiritual successor to curio [1]. The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing. The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I…

I was curious about [5] The link to support requests (which is a great piece of software) is here: https://cash.app/$KennethReitz Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law. Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards…

I wouldn’t say 33k is “almost zero.” For me, a single person living in the Bay Area, $33k would pay all of my expenses for a little over 6 months. When we’re talking about this amount of money going to a single individual, I don’t think it’s fair to call it “almost zero.”

Re: Why Is the Migration to Python 3 Taking So Long?

#85

Post by snagglegaggle »

mkesper wrote: post #66
CoolGuySteve wrote: post #47

Earlier quoted context omitted.

I find the stronger differentiation between bytes and strings leads to a lot of gotchas, like when I forget to encode bytes or pass a string where bytes are expected. I understand why it's the way it is, but when it comes the the typical unixy things I need to do shuffling of files around, tar'ing stuff, etc, it definitely trips me up more than I'd wish.

You at least notice it's wrong. In Python2 sometimes 'it worked' until it broke and you had to figure out why.

See, it just broke when UTF-8 was interpreted as ASCII. It's entirely possible to treat bytes as bytes and leave encoding out of it for the vast majority of programs. If you're dealing with text editing and so on, then you know you need to be UTF-8 aware, and the broken programs would still be broken in either language.

The visibility of the errors is a minor point, but I think it more appropriate that it be solved by e.g. the windowing toolkit API.

Re: Why Is the Migration to Python 3 Taking So Long?

#86

Post by LIV2 »

_skel wrote: post #71

I recently went through a fairly large upgrade from JDK8 to JDK 11 and it was a bit of a pain -- lots of dependencies to update, etc. But very few code changes were required, and the static type system made it pretty clear when the codebase was broken -- it just wouldn't build. It still took my team several weeks. Migrating from Python 2 to Python 3 is way worse than that -- code changes are required, and because Pyt…

Will this will make people less likely to use Python in future for some projects? I'm no developer or manager but I figure there'd be a thought in the back of my head thinking "what if we need to rewrite this all again for the next major release"

Re: Why Is the Migration to Python 3 Taking So Long?

#87

Post by fireattack »

viraptor wrote: post #67
Animats wrote: post #48

First off. Python 2.6 and 2.7 supported Unicode just fine. I had a large all-Unicode system in Python 2.6. You had to write u'word" to get a Unicode constant, and use a "unicode(s)" function here and there. Also, the part that remained "compatible" was that "str" remained an array of bytes, even though there was also a type "bytes" and a "bytearray". Early Python 3 was hell for conversion. The syntax was changed for…

> Python 2.6 and 2.7 supported Unicode just fine It did, but in a way that chainsaws support sculpting just fine. Technically possible. Very advanced people will know how to handle it. Everybody else is just going to injure themselves randomly. Most people writing py2 got the text/binary processing working on accident. Things appear to work until you throw actual Unicode into parameters and then nobody knows what hap…

Can vouch that as an amateur Python user from a country using "non-ASCII" language, py2 is a pain in ass when I was learning the language.

It didn't help that Py2's IDLE had (have? I didn't recall they actually resolved this, simply closed the issue) a major bug [1] that even if you explicitly use u-literals (a = u'日本語'), it will still be encoded in your locale (shift_JIS [2] in Japanese case), instead of unicode/utf-8. You can imagine how confused people would get when they were testing unicode support of py2 in IDLE and saw this.

[1] https://bugs.python.org/issue15809

[2] https://en.wikipedia.org/wiki/Shift_JIS

Re: Why Is the Migration to Python 3 Taking So Long?

#88

Post by SignalsFromBob »

semiotagonal wrote: post #13
downerending wrote: post #8

Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…

I wonder how many people feel that migrating to Python3 would have been worth doing in the absence of being forced to do so. Dropbox invested three years of work, actually hired Python's creator, and are still not done. What are they getting out of it that they wouldn't have gotten if Python2 simply had been maintained?

I suspect that someone, or a group of people, will step up to unofficially maintain Python 2 for the foreseeable future. It's clear that there are a lot of people using it that either can't easily migrate or are unwilling to do so for the various reasons already discussed in this thread.

Re: Why Is the Migration to Python 3 Taking So Long?

#89

Post by uranusjr »

erokar wrote: post #36
chungy wrote: post #20

Earlier quoted context omitted.

Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.

The nuisance of having to add self as parameter to every class method, no way of enforcing private methods and the mix between methods on objects and functions in the standard library. OO feels more integrated in e.g. Ruby. About some of the design decisions in Guido's own words: http://python-history.blogspot.com/2009/02/adding-support-fo...

I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started OOP (Java) trying to gork `this`, and I remember myself thinking “why didn’t everybody just do this” when I saw how Python declare methods. And I still think that’s a good idea now. So much easier to keep my sanity than using JavaScript’s bind.

Re: Why Is the Migration to Python 3 Taking So Long?

#90

Post by x0x0 »

downerending wrote: post #8

Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…

And the side-effect of an endless trail of shit to deal with. I write primarily ML code so until 3.5 or 3.6 python 3 offered me almost nothing better. It did, however, make managing environments even more of a mess. I quite frankly resented having to deal with code in both, swapping back and forth between python2, python3, pip2, pip3, etc.
Post reply on HN