8 ms·

I struggle with this whenever I think about it. On one hand I agree with all of the points you make. But on the other hand, it didn't have to be this way. Pytho

by jghn 6y ago

I struggle with this whenever I think about it. On one hand I agree with all of the points you make. But on the other hand, it didn't have to be this way. Python 3 has been out for 12 years now. If people hadn't dragged their feet on converting the mess wouldn't be nearly as large as it wound up being.

epistasis 6y ago
IMHO 12 years is a very short time! Of the user-facing programs I use (mostly CLI), the vast majority of the code That gets executed was written far longer ago than that. Writing some code and not have it executable a dozen years later is a terrible terrible situation. And it wouldn't be this way if Python 2 wasn't EOL. I'm going to always need to keep a copy of Python 2 around. Always. And if I'm going to change old, working code, I'm probably going to rewrite it in a new language.
- jghn 6y ago
  As with my previous post I'm torn on topics like this as again I agree with everything stated. And yet, Python was relatively niche in the early aughts so had only really been in the mainstream for a handful of years before 3.0 came out. What %age of live python code in the wild was written after 3.0 was released? I'd wager that's a very large number. But yet I get why things are the way they are. Heck, it was only last year that I switched to using Python 3. I use it so rarely that it was just easier to stick with the Python 2 which was already installed on my system.
cortesoft 6y ago
I am not sure why the length of time matters. They were spending the time doing other important things. They were making the rational decision to work on something that was important and WASN'T already working. The python 2 code was working fine, it didn't have bugs and it didn't need any new features. Other code either didn't exist and needed to be written or had bugs that needed to be fixed. It makes sense that changing working code never made it high enough on the priority list to get worked on.
umvi 6y ago
On the other hand, my company still has 25 year old C code that still compiles and works under the latest GCC, so...
- jjnoakes 6y ago
  And on the third hand companies I've worked with had 25-year-old C code bases that seemed to compile and mostly work, but mostly only with -O1 or lower, because they've had UB since the beginning of time but only more recent compiler optimizations reveal the underlying issues. And this old code is also written in a style (usually global variables and mixed concerns and years of sub-ideal bug fixes and patches) which makes it very hard to change or modernize (forget adding threads with all of this global mutable state). The only point being that old code may superficially work, but in many cases (in my experience) and regardless of language, it all has technical debt and needs work to keep it relevant.
  - Drdrdrq 6y ago
    Does that matter? The code performs its duty and has for 25 years. If there are bugs in it they clearly haven't been important enough to be fixed. Technical debt? Maybe, but if noone is collecting the fees, who cares? If the situation changes and the original code suddenly becomes a basis for further development then that's a different thing. But cleaning up the code without clear benefit is a waste of resources. Hats off to original developers. Making code that serves its purpose for 25 years is quite an achievement.
    - hanselot 6y ago
      As we force people over a certain age into retirement, perhaps this should happen for code bases as well.
    - jjnoakes 6y ago
      The code gets bug fixes occasionally because things change (scaling past previous limits, changes in the environment, etc) and of course new features are required once in a while. So the debt usually can't be swept under any carpets. All code rots. If you are lucky to never need to fix it or change it, that's great, but that is (in my experience) extremely rare over time spans measured in decades. Sometimes a code base runs for decades not because it was particularly robust or well-written, but because it is too painful to replace it due to its complexity or the long ago loss of the knowledge needed to work on it.
disown 6y ago
The problem is why should people be "converting the mess" in the first place. Backward compatibility, especially when it comes to programming languages, should be a given. If anything, this is reason that people should stop using python.
- mkoubaa 6y ago
  Python is FOSS. If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. That it didn't happen proves this is overblown
  - heavyset_go 6y ago
    There are entities out there with support contracts that stipulate Python 2 support for a while. Red Hat is one such entity[1]. [1] https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511
  - deleted 6y ago
    [deleted]
  - atoav 6y ago
    I guess there isn't really a propper need for a perpetuation of python27. This is mostly people who don't really see a difference between the versions other than that their print statements suddenly fail or that unmaintained dependency they used in that code half a decade ago complains. Who cares about the security pitfalls involved with using outdated python when tour code doesn't work? Of course python could have dealt better with backwards compatibility, but the python code I wrote was transfered to version 3 pretty quickly.
  - stock_toaster 6y ago
    > If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. Perhaps some chose instead move to other languages.
  - Jasper_ 6y ago
    It happened multiple times, and one of the times, the project needed to be renamed, causing a huge argument, lots of eyes on the project, and momentum to slow. There's a huge social cost to a fork. https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47
fiddlerwoaroof 6y ago
The dependency web makes it really hard to upgrade one part. You have to upgrade or rewrite all your dependencies and then do the same to your code: I tried this several times in the ‘07-‘12 timeframe and gave up each time: the cost wasn’t worth the benefits. Ultimately, I stopped writing Python: these days I write Common Lisp for personal projects and Clojure/JavaScript for everything else.
- donor20 6y ago
  It was made a lot harder by their efforts around intentional breakage. You couldn't do import from past (ie, to get print "" working). You couldn't do u'' to get unicode compatible string handling between both versions.

by jghn 6y ago

epistasis 6y ago

IMHO 12 years is a very short time! Of the user-facing programs I use (mostly CLI), the vast majority of the code That gets executed was written far longer ago than that. Writing some code and not have it executable a dozen years later is a terrible terrible situation. And it wouldn't be this way if Python 2 wasn't EOL. I'm going to always need to keep a copy of Python 2 around. Always. And if I'm going to change old, working code, I'm probably going to rewrite it in a new language.

jghn 6y ago
As with my previous post I'm torn on topics like this as again I agree with everything stated. And yet, Python was relatively niche in the early aughts so had only really been in the mainstream for a handful of years before 3.0 came out. What %age of live python code in the wild was written after 3.0 was released? I'd wager that's a very large number. But yet I get why things are the way they are. Heck, it was only last year that I switched to using Python 3. I use it so rarely that it was just easier to stick with the Python 2 which was already installed on my system.

cortesoft 6y ago

I am not sure why the length of time matters. They were spending the time doing other important things. They were making the rational decision to work on something that was important and WASN'T already working. The python 2 code was working fine, it didn't have bugs and it didn't need any new features. Other code either didn't exist and needed to be written or had bugs that needed to be fixed. It makes sense that changing working code never made it high enough on the priority list to get worked on.

umvi 6y ago

On the other hand, my company still has 25 year old C code that still compiles and works under the latest GCC, so...

jjnoakes 6y ago
And on the third hand companies I've worked with had 25-year-old C code bases that seemed to compile and mostly work, but mostly only with -O1 or lower, because they've had UB since the beginning of time but only more recent compiler optimizations reveal the underlying issues. And this old code is also written in a style (usually global variables and mixed concerns and years of sub-ideal bug fixes and patches) which makes it very hard to change or modernize (forget adding threads with all of this global mutable state). The only point being that old code may superficially work, but in many cases (in my experience) and regardless of language, it all has technical debt and needs work to keep it relevant.
- Drdrdrq 6y ago
  Does that matter? The code performs its duty and has for 25 years. If there are bugs in it they clearly haven't been important enough to be fixed. Technical debt? Maybe, but if noone is collecting the fees, who cares? If the situation changes and the original code suddenly becomes a basis for further development then that's a different thing. But cleaning up the code without clear benefit is a waste of resources. Hats off to original developers. Making code that serves its purpose for 25 years is quite an achievement.
  - hanselot 6y ago
    As we force people over a certain age into retirement, perhaps this should happen for code bases as well.
  - jjnoakes 6y ago
    The code gets bug fixes occasionally because things change (scaling past previous limits, changes in the environment, etc) and of course new features are required once in a while. So the debt usually can't be swept under any carpets. All code rots. If you are lucky to never need to fix it or change it, that's great, but that is (in my experience) extremely rare over time spans measured in decades. Sometimes a code base runs for decades not because it was particularly robust or well-written, but because it is too painful to replace it due to its complexity or the long ago loss of the knowledge needed to work on it.

disown 6y ago

The problem is why should people be "converting the mess" in the first place. Backward compatibility, especially when it comes to programming languages, should be a given. If anything, this is reason that people should stop using python.

mkoubaa 6y ago
Python is FOSS. If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. That it didn't happen proves this is overblown
- heavyset_go 6y ago
  There are entities out there with support contracts that stipulate Python 2 support for a while. Red Hat is one such entity[1]. [1] https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511
- deleted 6y ago
  [deleted]
- atoav 6y ago
  I guess there isn't really a propper need for a perpetuation of python27. This is mostly people who don't really see a difference between the versions other than that their print statements suddenly fail or that unmaintained dependency they used in that code half a decade ago complains. Who cares about the security pitfalls involved with using outdated python when tour code doesn't work? Of course python could have dealt better with backwards compatibility, but the python code I wrote was transfered to version 3 pretty quickly.
- stock_toaster 6y ago
  > If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. Perhaps some chose instead move to other languages.
- Jasper_ 6y ago
  It happened multiple times, and one of the times, the project needed to be renamed, causing a huge argument, lots of eyes on the project, and momentum to slow. There's a huge social cost to a fork. https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47

fiddlerwoaroof 6y ago

The dependency web makes it really hard to upgrade one part. You have to upgrade or rewrite all your dependencies and then do the same to your code: I tried this several times in the ‘07-‘12 timeframe and gave up each time: the cost wasn’t worth the benefits. Ultimately, I stopped writing Python: these days I write Common Lisp for personal projects and Clojure/JavaScript for everything else.

donor20 6y ago
It was made a lot harder by their efforts around intentional breakage. You couldn't do import from past (ie, to get print "" working). You couldn't do u'' to get unicode compatible string handling between both versions.