Hacker News new | past | comments | ask | show | jobs | submit login

Not sure what you mean.

This was the best way to do it. Slowly and painlessly. Any project that matters is now on 3.

For a bad transition, look at Perl 6, a debacle so big it was renamed Raku and became a different programming language.




Python tried to pull a Perl 6 and failed. Python 3 was done as a flag day, a big breaking change you need to switch over to. Originally Python 3 and Python 2 lacked features that would make it possible to write code that is compatible with both versions (like `u"foo"` syntax). Slowly they added things to Python 2 and 3 to make it easier to slowly transition.

But it was still full of unnecessary breaking changes.

- The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use.

- A lot of the incompatibilities are just stdlib modules being moved around unnecessarily. They could have made both import paths work for a transitional (deprecation) period. Or let the old paths continue to work forever, and just document usage of the new paths.

- All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2.

The only true breaking change was unicode literal strings. But again, that could be handled with a slow transitional (deprecation) period. The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have). And users could have been told to `from __future__ import unicode_literals` for a transitional (deprecation) period, to ensure their code is compatible before it becomes the default.

Basically Python 3 could have been a single hard breaking change (unicode literal strings), with a smooth transition. Instead they decided to make Python 2 and 3 diverge from each other, making it harder to do the transition.


> The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use.

They did, it's from __future__ import print_function. python2.7 was, essentially, the transitional deprecation period you mention, and it lasted a decade.

> A lot of the incompatibilities are just stdlib modules being moved around unnecessarily.

six.moves

> - All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2.

This assumes a level of similarity in the py2 and py3 codebases that isn't true in practice. There are different bytecodes and 3.0 only optimizations. Backporting some of these is possible, but not a reasonable burden.

>The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have).

I don't know what you're working with, but most third party libs aren't compatible with both types of strings. They're compatible with str or bytes, but not both except in rare and usually wrong cases.

Importing unicode literals only sometimes solves the issues, and often times introduces different problems.


I think next time, when you need to do breaking changes, give it a new name, so the new thing gets to be hot and new, rather than a problem.

Or do what javascript did: stay compatible with the stupid old way, but build a brand new language on top of it.


That's exactly what Perl has been doing since 1987.

Where do you think the idea for `"use strict"` in JavaScript came from?

    use v5.8;
    use strict;
    use warnings;


> - The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use.

The print statement dates to antiquity (cf. BASIC) and could certainly coexist with the print() function. It was a nice and friendly piece of syntax whose removal was entirely unnecessary.

Now that Python is free of GVR, perhaps we can restore the print statement to its rightful place in the language! ;D


> For a bad transition, look at Perl 6

At first glance, you're right. But if you take a closer look, from a purely pragmatic perspective, there are now at least two coexisting ecosystems in two different languages, peacefully sailing along.

Python 2/3 is in this kind of weird twilight zones that the two versions are far away enough that you can't have a smooth transition like in e.g. C++, Java, Rust, Go, etc., but still close enough that there is not a clear cut like in Perl5/Raku. So for a few years, one had to juggle with some of the libs that were 2-and-3 compatible, some that were 2-only, and the others that were 3-only.

C++ et al. let your code evolve Theseus ship-like; Perl makes you build a new ship; and Python tells you that your ship should be OK if you repaint that thing, change a bit of that one, oh, and by the way, you'll have to check very carefully your bunkers, because the boilers will explode if every coal nut is not Unicode-compatible.


> This was the best way to do it.

Was it really though? Speaking as somebody who considered learning Python several times over the course of a decade I was seriously put off by the protracted uncertainty around 2 vs 3.

There was a long period - years long - where everything that "mattered" seemed to be supported by and available for Python 2 and there was a ton of FUD, along with genuine issues, about incompatibilities with Python 3. When I asked which version I should learn I felt like I couldn't get a straight answer.

I never had a strong need to learn Python: I just thought it might be a fun and useful thing to do, because people seemed to like the language. But I wasn't interested in investing time in something that might wind up unsupported in a few years, and because I didn't have any serious need for it, it wasn't worth digging through the morass of misinformation to get to the truth.

As an outsider it was extremely unclear to me which version of Python would be actively supported for the long term. 20:20 hindsight says 3 was the future but - and maybe this is just bad mar-comms - back then it seemed like there was a reasonable chance it was either going to be a dead end or exist perpetually in this weird no-mans-land of "not quite ready for prime time".

Had I learned it there's a good chance I probably would have used it for something more serious by now. But I didn't, and so I have to disagree: it was done extremely poorly.


> Speaking as somebody who considered learning Python several times over the course of a decade I was seriously put off by the uncertainty around 2 vs 3.

And yet Python is still one of the most popular programming languages, with its popularity and use growing.

Theoretically it could have been done better, but it was going to take time no matter what approach you took and it worked out in the end.


I don't really understand why there has been so much hemming and hawing about Python 2 vs Python 3 with regard to the language itself. If you already know a few programming languages (rather than being a neophyte coder), Python 2 and Python 3 are so similar that their major differences can be summed up in one or two pages of code examples. Sure, they're not backwards compatible, but if you know one, you'll have no trouble being able to at least read and understand the other without much effort. The bigger issue is the ecosystem taking the time to catch up. Also, I'm not sure that Python 3 is really much of an improvement over 2 rather than just different.


The plan was for people to write Python 2 and generate Python 3.[1] What eventually worked was making it possible to have a single code base. Imagine if that had been possible all along.

[1] http://python-notes.curiousefficiency.org/en/latest/python3/...


It was, by any standard, just about the worst way to do it.

Fractured community Lost trust Endless bikeshedding

All for very little objective gain.


The language is pretty sweet. I guess nothing that you can't do other languages, but it has some good mojo now it's raku.


Nope, perl was mentioned just above. This was the second worst way. ;-)


The distinction I would make is that they never told anyone to migrate production code to Perl 6.


They couldn't even if they wanted because it didn't ship for twenty years.


Correction 15 years.

I was using it to an extent in 2009. (I'm sure I was using it before that.) At which point it had only been 9 years in development.

---

You can have it fast, good, or cheap. Pick at most 2.

Since Perl 6 was entirely volunteer driven it was always going to be cheap. So the only real choice was between fast and good.

I'm glad the choice was to make it good rather than fast.

We could have gone the Python route where they chose fast. Only they didn't really even manage to do that much better than Perl6.

---

And what did Python get, a language that is only slightly better in a handful of ways. (Every one that I've heard of is reminiscent of one that Perl5 has dealt with over the years without breaking backwards compatibility.)

Perl6 meanwhile is a large step that questions long held beliefs of what a programming language can even be. It calls into question what parsers can be, what regexes can be. It calls into question why language divides exist. Why can't a language be at both ends of the spectrum at the same time.

Even if Raku doesn't take off, it will likely be a source of inspiration for future language designers. (It already has to a small degree.)

Whereas Python3 is just a slightly nicer Python. One that not everyone has transitioned to yet. Some may never. (Some have even transitioned to Go instead, since it has very similar semantics.)

---

There were also some health issues during the Perl6 project which held back the progress to a significant degree. We don't know how many years that added to the total.


But that’s why Python is much worse than Perl. The Python team was trying to move the world to 3 when it was demonstrably inferior


If only we all could fail so spectacularly, growing an order of magnitude in the same time period. I wouldn’t use Python 2 now if you paid me.


A backwards compatible and incremental move would have been much better. Microsoft has been doing that on C#, can't be happier.


v8 matters and still requires Python2 to build.

https://bugs.chromium.org/p/chromium/issues/detail?id=942720


Bringing up Perl 6? That was a low blow. ;-)

I'll be dead in my grave before I recognize anything past 5.8.1.

Just like how they still haven't made The Matrix 3.

Sh. Quiet, you. :)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: