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

281–290 of 355 posts

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

#281

Post by michaelmrose »

someguydave wrote: post #268
pbreit wrote: post #256

Earlier quoted context omitted.

I am flabbergasted every time I see a software project eschew backwards-compatibility. No one wants to spend energy re-programming to stay in place. Especially APIs.

Yes python 3 was clearly a mistake. There could have been less hostile ways to make improvements in the language.

Probably the mistake was not dropping support much sooner.

Python 3 came out in 2008 so say no backported features after 2009 no bug fixes after 2012. All announced in 2008 of course.

Given 4 years to migrate most would have made the jump sooner.

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

#282

Post by acqq »

acqq wrote: post #145
jnxx wrote: post #133

Earlier quoted context omitted.

> 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... Common Lisp has a backwards compatibility which goes into decades, and implementations like SBCL had no difficulties at all to absorb Unicode. Racket even supports different language standards and completely different languages (such as Scheme and Algol) running on the s…

> But the incompatibility between Python 2 and Python 3 is perhap s only a symptom of a larger problem. The Python developers have decided that backwards compatibility is not that important any more. Exactly: and that was a wrong decision for anybody but the developers of Python. Everybody else prefers having something that works: "The improvements are welcome, but please allow us to to run our old programs too, than…

As an example for Linus' "kernel changes should not break user programs" policy, he was famous for using harsh words to pass the message to those who tired to steer otherwise (these words I don't have to repeat, so I'll just quote his main message):

https://lkml.org/lkml/2012/12/23/75

"How long have you been a maintainer? And you still haven't learnt the first rule of kernel maintenance?

If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs."

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

#283

Post by michaelmrose »

Johnny555 wrote: post #202
ageofwant wrote: post #171

Earlier quoted context omitted.

Again with the 'Tremendous amount of effort' meme. I've done many ports and they were all trivial: - run 2to3 - spend 2h max fixing any failing tests - cook of any remaining issues in a few days of beta testing like you'd do for any new release Now now doubt Python 2.7 is a excellent and solid release and will remain so for as long anyone keeps the bitrot in check, but to keep using it because porting is 'hard' is pa…

It's not so much that it's "hard", but that it's time consuming when you have hundreds or even thousands of python scripts to port -- and since those scripts already work and you probably weren't going to have to touch them at all, you're not really gaining anything for all of that porting effort.

Maybe whomever should have stopped writing new ones by 2009 a decade ago.

Then you wouldn't have much to port.

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

#284

Post by int_19h »

adrianN wrote: post #254
rstuart4133 wrote: post #250

Earlier quoted context omitted.

> Actually that's the behavior of python 2, it works fine, until you send invalid characters then it blows up. Not that I've seen. Example of where Python 3 has rained shit on my parade: I wrote a program that backs up files for Linux. It works fine in python 2, but in python 3 you rapidly learn you must treat filenames as bytes otherwise your backup program blows up on valid Linux filenames. It's not just decoding e…

Filenames need to be treated as binary because of bad designs decades ago. Rust handles this correctly imho, by having a separate type for such strings, OsStr.

Python has pathlib nowadays. But I'm not sure whether that stores them as raw bytes or Unicode internally - the API provides for either.

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

#285

Post by int_19h »

takeda wrote: post #258
dyingkneepad wrote: post #201

Earlier quoted context omitted.

> Actually that's the behavior of python 2, it works fine, until you send invalid characters then it blows up. > In python 3 it always blows up when you mix bytes with text so you can catch the issue early on. Sometimes you don't care about weird characters being print as weird things. In python 2 it works fine: you receive garbage, you pass garbage. In python 3 it shuts down your application with a backtrace. Dealin…

Those issues are common when you're having python 2 code that uses unicode datatype and you have a task to migrate it to python 3. You run your python 2 code on python 3 and it fails, most people at that point will place encode() or decode() in place where you have a failure. When the correct fix would be to place encode/decode at I/O boundary (writing to files (and in python 3 even that is not needed if you open fil…

The worst part about Unicode in Python 2 isn't even that everything defaults to bytes. It's that the language will "helpfully" implicitly convert bytes/str, using the default encoding that literally makes no sense in practically any context - it's not the locale encoding. It's ASCII!

Native English speakers are usually the ones blissfully unaware of it, because it just happens to cover all their usual inputs. But as soon as you have so much as an umlaut, surprise! And there are plenty of ways to end up with a Unicode string floating around even in Python 2 - JSON, for example. And then it ends up in some place like a+b, and you get an implicit conversion.

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

#286

Post by int_19h »

downerending wrote: post #181
ogre_codes wrote: post #164

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…

There was no way to gradually improve Unicode support in Python without breaking things, because a big part of it was stuff like implicit str/unicode conversions - that were broken because they practically never use the right encoding, but that you can't remove without introducing as much breakage as Python 3 did.

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

#287

Post by int_19h »

bobbylarrybobby wrote: post #99
coldtea wrote: post #69

Earlier quoted context omitted.

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

JS and Java can do that because they were designed reasonably well from the start. All they tend to add are more features on top of the solid core language. Python's language was not solid (e.g., strings not unicode by default) so they needed a major overhaul.

It's funny that you should bring up Unicode strings as an example. Java strings aren't Unicode by modern standards - their char is fixed as 16 bits, because back in the day, UCS2 was "good enough for everybody". So the moment you have, say, an emoji, stuff like length() and indexing is no longer dealing in actual codepoints. And you can slice in the middle of a surrogate pair, and end up with an instance of String that's not even valid UTF-16.

Python didn't get Unicode until later, so it had a chance to do it right - and it finally did, even on platforms like Windows where wchar_t is also 16-bit for historical reasons.

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

#288

Post by int_19h »

joshuamorton wrote: post #210
biggestdecision wrote: post #180

Earlier quoted context omitted.

The syntax of a language is an abstraction over what is actually going on under the hood. There's no reason python couldn't have designed their OOP abstraction more elegantly.

Why is self.foo more elegant? It's very rare that you'll call a given method as self.foo, and there's a slew of complications that come with such a syntax (the declaration grammar is more complex, `self` is now special, etc.) It's true that languages are abstractions, but not all abstractions are useful.

It doesn't have to treat "self" as a special keyword - it just has to desugar "foo.bar(x, y)" into "bar(foo, x, y)". There are some other languages that do that - e.g. in F#, you write:

   member this.foo(x, y) = ...
Again, "this" is just an identifier here, and doesn't have any special meaning.

It's more elegant firstly because it follow use, and secondly because it means that "def foo(x)" has the same meaning both inside and outside of a class declaration - it's just a function, and there's nothing special about its first argument. As it is, we need stuff like @staticmethod and @classmethod. It's especially annoying when you have class attributes that happen to reference a function, because conversion from functions to methods is a runtime thing - so you have to remember to wrap those in staticmethod() as well.

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

#289

Post by akx »

musicale wrote: post #237

Because they broke backward compatibility in very annoying ways without providing a fallback mechanism. I still haven't forgiven them for killing the print statement, which could have peacefully coexisted with a print() function.

Having two ways to do the same thing is against The Zen of Python.

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

#290

Post by int_19h »

AnimalMuppet wrote: post #144
dragonwriter wrote: post #41

Earlier quoted context omitted.

I think for some people having the receiver as an explicit parameter of methods rather than references through a special syntactic variable bothers some people and makes it look to them like a procedural language playing OO, though I personally think it's the most clear representation of what every class-based OO language actually does operationally, since methods are attached to a class and take a reference to the i…

It may in fact be what every class-based OO language actually does operationally. But having the OO language do that for you is, to me, one of the lines that separates them from "a procedural language playing OO".

How would you describe OO languages which only have multimethods, then? Say, Dylan?
Post reply on HN