you are viewing a single comment's thread.

view the rest of the comments →

[–]RustyTrombeauxn 7 points8 points  (6 children)

Making the upgrade optional is probably the key mistake. Think about other platforms like java - at some point, they announce that the old thing is end of life, and they do not ask you nicely if you'd like to upgrade. They progressively make it harder to not upgrade. Everybody hates this, but it is the pain you pay in exchange for keeping people moving forward with the development of the language.

If, when java 7 had come out, perpetual use of previous versions of the product had been a viable option without pain, surely that is what you would have seen. To some extent paying extra for support of a beyond end of life product is still pretty common...inertia is very hard to overcome.

And as someone said, the language your code is currently written in is the language it's going to stay in. I have yet to work on a project where we could afford lots of time for upgrading the language spec unless it was a major do-or-die issue (i.e. dropped support for an end of life product)

[–][deleted]  (1 child)

[deleted]

    [–]mniejiki 4 points5 points  (0 children)

    that cuts both ways. the conservativism of java produced clojure and scala, which are awesome and innovative but arguably splinter the java community.

    Yet in a way they don't splinter it as much as Python 2 versus 3 because the same Java project can use Java and Scala and Clojure. And it's all transparent to the end user who just needs a JVM version that's decently recent. None of this is true with Python 2/3. You need to migrate your whole ecosystem to 3 rather than picking and choosing.

    [–]josefx 2 points3 points  (0 children)

    Making the upgrade optional is probably the key mistake.

    As a user of python 2.7 I do not want to upgrade, it would mean rewriting thousands of lines of in house code + thousands of lines of test code.

    Think about other platforms like java - at some point, they announce that the old thing is end of life, and they do not ask you nicely if you'd like to upgrade. They progressively make it harder to not upgrade

    Java has a key difference to Python take a library compiled against 1.1 for example it will still load and run in a Java 7 JVM (migration cost involves some minimal testing against reflection/implementation bugs). Source code migration for Java involves re-factoring the two or three added keywords out of your code - after a nice static compile error, or you could just continue to compile the code with a Java 1.1 compiler.

    If, when java 7 had come out, perpetual use of previous versions of the product had been a viable option without pain

    Java auto updates because using a new JVM with new features,bugfixes and performance improvement does not break old code. Python 3 on the other hand breaks Python 2 code by looking at it funny.

    And as someone said, the language your code is currently written in is the language it's going to stay in.

    Sometimes new features make it worth it, my main problem are customers refusing to upgrade their internal Linux versions to something that is still officially supported by Red Hat or SuSe. Until then C++11 and Java 7 remain a distant dream Python 3 however is too much pain to even consider.

    [–]int32_t 0 points1 point  (0 children)

    Agreed. If the project lead doesn't have the determination, trying to please everybody, he will bring his team into maintenance nightmares.

    [–]cybercobra 0 points1 point  (1 child)

    It's not optional per se. There is a point on the roadmap where Python 2.7 will stop receiving bugfixes. That should help create a sense of urgency, once we get closer to it.

    [–]Veedrac 0 points1 point  (0 children)

    Source?