Live data from Hacker News

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

191–200 of 355 posts

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

#191
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…

"Just fine" fails as soon as someone does isinstance(foo, str) in 2.x. If foo was a unicode object, well it sucks to be you. There are a lot of footguns in the old string handling. Python 3's fail fast approach ensures they get caught early on.

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

#192

Earlier quoted context omitted.

This is a hugely American point of view. For anyone who has to deal with unicode on a regular basis, the better unicode support alone is a huge improvement. That's without even looking at the advantages of Async support which offers big performance benefits for web developers—roughly 70% of Python users.

Note that the question is not "Shall we support Unicode?". Clearly we should. The question is rather whether it would have been better to gradually improve support for it in a Python2-esque way, rather than creating a discontinuity and a raft of new problems, some of which linger to this day. Also, for many purposes, there is wide agreement that ASCII is still the way to go. Even if Americans vanished tomorrow, the m…

You are replying out of context here. The comment I was replying to was specifically "Python3 still didn't deliver anything for most users". Which is just not true.

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

#193
post #56
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…

They still did stuff that makes no sense, to me, like not supporting `iteritems` on dictionaries and `xrange` on sequences. Or using `str` to mean bytes? That would have been possible to make backwards compatible until Python 4. At this point, does anyone think there will be a Python 4?

You're expected to clean that stuff up with 2to3. The whole idea is to not leave band-aids in place.

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

#194
post #128

Earlier quoted context omitted.

Almost everyone hates both Java and Javascript.

Javascript is a hugely popular language, as is Java. Some hipsters hate "Java and Javascript". The world at large loves them. At some point plain users hated Java applets and Java desktop apps, but those are not a thing much more. In the server space, very few that use it hate Java, and millions use it.

Just because they're popular doesn't necessarily mean their users like them.

Lots of people learn and use these languages because:

1 - That's what they're taught at school.

2 - That's where many if not most programming jobs are.

3 - There are a bazillion libraries they can use, compared to other languages.

4 - JS is built in to browsers.

5 - They don't know any better.

6 - Marketing.

Also, many companies want their staff to develop in these languages because of the reasons on this list plus that's what most programmers know, so it's relatively easy to find employees.

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

#195
post #123

Earlier quoted context omitted.

On the topic of not enough carrot, I’m curious how impactful the end of support for python2 will be. How many programs stuck in python2 are encountering bugs in the runtime?

Python itself won't be as much affected, what will affect you most are your dependencies. Imagine using a library and running in some kind of bug. You check newer version, looks like that bug was fixed, but the library now only works on python 3.6+. What will you do?

Backport the fix from 3.6, or just implement a fix yourself?

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

#196
post #69

Earlier quoted context omitted.

This is backwards thinking. Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. But failing that, expecting the Python team to support the older/ less functional version of the code indefi…

> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

No, 'cargo culting' is when you don't understand the causal link between cause and effect. Of course "newer is better" in this case, and we know exactly why: Thousands of man days have been spend improving underlying libraries, lessons have been learnt, new ideas stolen from other languages, optimization, security improvements and so on.

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

#197
post #160

Earlier quoted context omitted.

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

> In python 3 it always blows up when you mix bytes with text so you can catch the issue early on. This is definitely the case. I've been wrestling with bytes and strings all the time during the port of a Django application to Python 3 for a costumer. I can see myself encoding and decoding response bodies and JSON for the time being. For reasons I didn't investigate I don't have to do that with projects in Ruby and E…

I’ve worked in a variety of Django codebases, and the last time I had trouble with string encoding/decoding was with Python 2. Since moving to Python 3, I have rarely needed to manually encode or decode, and I genuinely can't remember the last time I did.

Perhaps there’s something about a port that requires encoding/decoding bytes/strings?

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

#198
post #86

Earlier quoted context omitted.

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"

What I've been seeing is people using Python 3 for new projects but leaving their older projects on Python 2. As a result of that, Python 2 will continue to be supported internally at a lot of companies, even though it is "officially" end of life. Nobody wants to rewrite the stuff they finished years ago that is now in maintenance mode.

I considered doing this myself, but decided that I didn't want the hassle of having two versions of Python hanging around.

If/when the day comes that using Python 2 isn't realistic, I may go with 3, or I may choose a different language, depending on the project. I'll cross that bridge when I come to it.

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

#199

Earlier quoted context omitted.

Behold the tremendous amount of effort for Mercurial: https://www.mercurial-scm.org/repo/hg/log?rev=py3&revcount=2... They've been porting hg into Python 3 for the last 10 years and are only now nearing completion. I've written a bit more about this in Lobsters: https://lobste.rs/s/3vkmm8/why_i_can_t_remove_python_2_from_...

Yes of course there will be exceptions. But the vast majority off Python code bases are not mercurial or dropbox or imgur. Just like the vast majority of software using companies are not google or facebook. The average few hundred to few thousand loc app, which should be 98% of all production code-bases will almost certainly port with no issue.

You're assuming a lot.

What about codebases with python2 third party dependencies that don't work in python3? Now you have to port that entire library as well, or write it yourself while crossing your fingers that it is well documented and easy to work through.

What about codebases without decent test suites? I'd argue most production codebases don't have good test suites, or at least the most complex of code is usually poorly tested. You'll end up spending most of your time digging for regressions especially if your code creates large amounts of user interfaces.

What about code bases that were written by scientists, mathematicians, or other professionals who may not be as fluent in writing "good" code?

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

#200

Earlier quoted context omitted.

>JS manages to do that just fine How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes. And JS "The good parts" is like 1/10 of the full language so often it feels like a lot of pile on. >as does Java How are them generics?

> How do you define just fine? Besides the total domination of the web programming space, which is of course aided by it being the only option: 1) Used by choice even on the server and application development (where it was never the only option, and wasn't even preferable/viable before) 2) Fast pace of language development 3) A thriving package ecosystem with millions of packages 4) Adopted by all major companies 5)…

And yet Python is eating the world: http://pypl.github.io/PYPL.html

Not that I'm implying that 'popularity' is a good measure of anything.

Post reply on HN