1. 33
  1. 10

    Python 3 will also go down in history as “a bad way to release software that breaks backwards compatibility.”

    Now I’m biased as fuck in saying this but PHP sure learned a lot from Python and isn’t the language it once was since it’s released 7(.1, .2).

    1. 1

      PHP sure learned a lot from Python and isn’t the language it once was since it’s released 7(.1, .2).

      I haven’t used PHP since 5 was released a few years ago. What has changed? And how has the community changed course significantly without breaking backwards compatibility?

      1. 4

        They slowly break backwards compatibility with each point release (as they did throughout 5). A lot of people have strongly embraced PHP 7 and I think the biggest advantages right now are scalar type hints, anonymous classes, and the engine is fast as heck. Its a much brighter landscape too with frameworks like Laravel, Symfony, and they’re even moving out of the request/response model with stuff like ReactPHP.

    2. 11

      Public reminder that Python 3 was released 10 years ago, while Python 2 was only 8 years old when Python 3 was released. That’s some spectacular mishandling of a new software release.

      1. 2


        1. 4

          I think the point they’re trying to get at is that Python 3 is older than Python 2 was, when Python 3 first came out. Python 2 code is still very prolific, and anecdotally I’m seeing people still starting new projects with Python 2.

      2. 2

        Good, and it is already late. Python 3 at this moment is far superior to 2.7, time to move on.

        1. 2

          The whole Python 2/3 debacle is why I gravitated to Ruby, which has its own set of warts.

          So what are the lessons learned?

          1. 2

            Incidently, the reason I moved from Ruby was the 1.8 era where I think there was also a rails 2/3 upgrade at the same time, wasn’t fun. Lesson learned is the one of the biggest obstacles of our job is unsupported software, be it a library or a language, as long as it works and solves your problem, it’s not the end of the world.

            And just because software is marked as unsupported, it doesn’t mean all the knowledge for X software projects also disappears over night.

            Or we can just write everything in assembly.

            1. 1

              No matter what tools you choose to use there are going to be things you don’t like about them. And that’s okay, you just have to pick a set of warts you can live with.

            2. 0

              So this means whatever you write in python today, you will have to re-write it again in 8 years ?


              Maybe tools like 2to3 make it easier though…

              1. 8

                Guido has shared this article stating that no more breaking changes are expected in the future :

                a 4.0 will presumably still happen some day, and the premise of this article is expected to hold for that release: it will be held to the same backwards compatibility obligations as a Python 3.X to 3.X+1 update.

                1. 1

                  This is a great news!

                2. 4

                  Basically none of the Python community wants to experience the 3.0-style backwards compatability issues again (this includes core developers).

                  Something that might get lost in the noise, but 3.0 in particular broke a huge amount and there was relatively little concern for having code that could run in 2+3. But after the feedback they had introduced stuff back into 3 (like allowing the no-op u'..') and made it easier to run both-version-compatible code. So 3.0 was especially broken.

                  Guido has said that any compatability breakage nowadays would happen piecemeal, and with more care to this issue. Presumably it would have been something like “string literal changes” in one release, “urllib changes” in another release, etc. Instead of forcing all changes all at once.

                  1. 4

                    So this means whatever you write in python today, you will have to re-write it again in 8 years ?

                    That’s a completely unfounded statement.

                    1. 5

                      Ended with a question mark, I’d assume a legitimate question. Also the answer to it would be “not necessarily, and if you’re writing it in Python today, this might convince you to write it in Python 3”

                      1. 1

                        I am still new to python, so this is more of a clueless question than a statement like olivier wrote.

                        So as I understand it, it might have been the case 8 years ago, but as edudobay points out, what comes will be much better.

                        1. 4

                          When I migrated 8 projects from python 2.7 to 3.4 (few years ago now) it only took me about a day, it really wasn’t as painful as it was made out to be. Before any big changes are planned the documentation usually suggests ways to structure current code that won’t break future releases.

                          1. 1

                            Then I understand what lead me to thinking this: I have seen a quite large code base (glue between daemons and an API) wait till the latest minute (now I guess) before to switch from 2.5 to python 3.

                        2. 1

                          I understand what lead me to think this (as answered to crookey).

                        3. 2

                          I’d be suprised if they were to actually include a switch, which would any python2 interpreter just immediately quit whenever it’s started after 1/1/2020. But guessing that they won’t do that, I’d suppose that most people will be allowed to keep on using the interpreter, even if it isn’t maintained anymore.

                          1. 2

                            That’s my reading too.

                            In any case, there’s nothing stopping someone from forking the code, as Guido points out.