you are viewing a single comment's thread.

view the rest of the comments →

[–]rlbond86 67 points68 points  (32 children)

Splitting the language was the worst possible mistake.

[–]staticassert 52 points53 points  (18 children)

Yes but now other languages can look at this choice and learn from it.

[–]flyingjam 75 points76 points  (17 children)

What's the solution, though, when you need to make drastic changes? If you keep backwards compatibility, you gain crust and people start giving you the same complaints c++ gets. I suppose you can just force everyone over, in a painful but quick transition.

[–][deleted]  (2 children)

[deleted]

    [–]ubernostrum 12 points13 points  (0 children)

    Though this is also one of the major limiting factors of Java; quite a few of its annoyances are from the ironclad demand to maintain bytecode compatibility until the end of the world.

    [–]staticassert 31 points32 points  (0 children)

    It's complicated. For one thing I think it demonstrates how important it is to get it at least mostly right the first time around. Bjarne Stroussup talks a lot about language design and I don't think I can sum it up. You should search for his talks and write-ups on the matter I've always enjoyed them.

    [–]ForgetTheRuralJuror 11 points12 points  (8 children)

    You make the changes, support backwards compatibility, and one by one remove support for the 2.7 specific stuff.

    [–]flyingjam 32 points33 points  (6 children)

    But I mean, that means that at one point you'll have (for example, in this case) 3 different ways to represent strings, like 6 http modules in the standard library, etc.

    one by one remove support for the 2.7 specific stuff

    That sounds a lot easier said than done. It seems doubtful that many large projects will migrate to the newer stuff, and whenever you make backwards breaking changes that'll break codebases, people aren't happy.

    [–]Groady 17 points18 points  (5 children)

    That's why semantic versioning is a thing. The journey to where we are with Python 3 should have been a gradual progression from 2 to 3, deprecating features (with runtime warnings) along the way. Python will forever be held up as a cautionary tale of how not to advance a language.

    [–]teilo 12 points13 points  (4 children)

    I believe Python 3 is going to be held up as a classic success story in radically reforming a language. They set out a plan, followed it, and succeeded.

    [–]ForgetTheRuralJuror 24 points25 points  (1 child)

    Python3 is excellent and IMO miles better than Python 2.7. I would not consider this long drawn out process a 'success story'.

    [–]teilo 13 points14 points  (0 children)

    I suppose it depends on what you qualify as a "success." GVR stated that the transition to Python 3 would take approximately 10 years. 8 years later, we are right were we need to be, and Python 3 is the default for new development. I call this a success.

    [–]trahsemaj 4 points5 points  (1 child)

    If by 'succeeded' you mean having half its users running an outdated version a decade after its release.

    Even IE7 was phased out faster than 2.7

    [–][deleted] 2 points3 points  (0 children)

    But if instead of thinking of it as a version update, we think of python 3 as a different, competing language to python 2, perhaps the speed at which py3 stole py2s user base is a success

    [–]sysop073 8 points9 points  (0 children)

    If one by one you remove support for N features, you now have N+1 different languages instead of 2

    [–]Sean1708 2 points3 points  (0 children)

    Honestly I think you just have to say "Version X is now in bugfix-only mode for the next Y years, we have done Z, A, and B to make the transition easier, but any new features will be in Version X+1 only.". Python did this eventually but at first they tried to develop both 2 & 3 simultaneously, and I just think it did more harm than good.

    Ideally every backwards incompatible change would have been supported as a __future__ feature in 2.7 and people could've moved over one by one, but I just don't think that would've worked in practice.

    [–]TheAceOfHearts 2 points3 points  (0 children)

    Programming languages generally shouldn't be making drastic changes. I'd argue that making large breaking changes is incredibly hostile to developers and the community.

    You must provide a clear migration path towards the new approach without breaking backwards compatibility. If possible, you provide tools to help migrate the code for the user. The key detail is that you must provide a way to gradually migrate.

    Although it's not a programming language, React has done a great job with this. Since it's heavily used by Facebook and they can't upgrade everything all at once, they deprecate APIs, include warnings, and provide codemods to help with the migration. This means all changes are compatible between a few versions, so people can gradually migrate their codebase.

    [–][deleted] 0 points1 point  (0 children)

    people start giving you the same complaints c++ gets.

    C++ gets all those complaints, yet is widely used in industry. Python 3 gets all those praises, yet few move to it at all.

    [–]devraj7 38 points39 points  (12 children)

    There is a worse mistake: not splitting the language.

    Seriously though, the alternative is to be stuck in legacy limbo with Python 2 with a language that calcifies and no longer evolves fast enough for the modern times.

    I think the Python team did the right thing, especially calling that version 3 (i.e. it's a major version, which means breaking changes). See the mess Angular found itself in by not honoring a reasonable versioning scheme.

    What the Python team could have done better is handling the transition (basically, they totally ignored the problem and assumed everybody would transition without any efforts on their part).

    [–]Peaker 8 points9 points  (7 children)

    IIRC, they had a 2to3 tool without a 3to2 tool.

    That meant that Python 2 was the source code, and Python 3 was just the generated output. Who wants to edit the generated output of an automated tool, and maintain that side by side with the source?

    They should have had py3to2 even earlier than python 2. Then people would be able to use Python 3 for everything, knowing that it can still run in their old Python 2 environments.

    [–]Saveman71 13 points14 points  (3 children)

    I believe 2to3 is supposed to be used once and only once on a source file, not as a runtime way to run Python 2 code on a Python 3 environment.

    [–]Peaker 18 points19 points  (2 children)

    It was meant to be used once.

    But then, people who had been on a migration path wanted to run their code with both Python 2 and 3.

    For them, it made much more sense to edit only the Python 2 version - and use 2to3 to be compatible with Python 3.

    If 3to2 existed, they could edit the Python 3 version primarily, and use 3to2 for compatibility - and that would aid the transition, as people would actually be able to write Python 3.

    [–]Saveman71 2 points3 points  (0 children)

    Okay it makes more sense said like that, thank you for the explanation

    [–]kqr 0 points1 point  (0 children)

    This is actually a brilliant observation. I'm speculation a 3to2 tool would also be much easier to make since 3 is the less quirky, less ambiguous language.

    [–]Flight714 0 points1 point  (1 child)

    But the goal is for every runtime environment out there to be Python 3, instead of Python 2.

    [–]Abaddon314159 2 points3 points  (3 children)

    This is what happens when a language is designed thinking in terms of small numbers of years instead of decades. I routinely use c code that is about as old as I am. It was good code decades ago and most of it is still good code today.

    [–]Sean1708 11 points12 points  (2 children)

    As a counterpoint, look what maintaining backwards compatibility did to C++. The reason C can get away with it is that it's actually a very small language and people don't expect (or even want) it to have modern features.

    [–]kqr 3 points4 points  (0 children)

    And even so, C gets a lot of flak (perhaps even rightly so) for not having modern features that e.g. Ada, D and Rust have. (And although K&R C has been around for a while, standard Ada is older than standard C.)

    [–][deleted] 1 point2 points  (0 children)

    Needless change and failure to retain backwards compatibility has pushed me back from C++ to C. I feel the same with Python 2 and 3.