4 ms·

Python 2.7 was supported for 9+ years, python 3 was released in 2008, with development beginning before then. You had almost 15 years of warning from initial an

Python 2.7 was supported for 9+ years, python 3 was released in 2008, with development beginning before then. You had almost 15 years of warning from initial announcement to eol. Python3 predates golang. > And they could have done a lot more to make the transition easier if they wanted to - some of it was just in your face type breakage to a prove a point without considering some underlying use case Such as? > (a lot of internet protocols headers etc still ASCII). What do you mean here? Py3 correctly handles http headers encoded as ascii bytes. Yes the decision to make http headers ascii bytes and not basically anything else is bad in hindsight, but that ships sailed.

ornxka 6y ago
>You had almost 15 years of warning from initial announcement to eol. Why should I have to do labor to fix things that already work?
- CogitoCogito 6y ago
  > Why should I have to do labor to fix things that already work? You don't right? Python 2 still works.
- michaelmrose 6y ago
  Maintaining python2 and python3 forever in perpetuity wouldn't be free either. Why should they provide free labor in perpetuity so that you need no provide any? In theory if there was sufficient need the entire community of python2 users could collectively fund said support but I don't see how they can demand it for free.
- takeda 6y ago
  You don't have to it's not like PSF made Python 2.7 stop working on January 1st 2020.
- isbjorn16 6y ago
  You don't need to, provided you're willing to also maintain a Python 2.x fork on your own instead, or willing to pay someone else to do it for you, or willing to risk no more patches to the interpreter. You do you, boo.
russfink 6y ago
Even a simple message in an exception statement, "you are running Python 3; could this be Python 2 code?"
- joshuamorton 6y ago
  I claim that this would have negative EV. Most exceptions aren't due to version mismatch. You could add a line for a very specific set of syntax errors, but those aren't very useful. Also having your new version suggest using the old version is counterproductive.
  - Drdrdrq 6y ago
    Maybe... But there are two correct solutions (using an old version or upgrading the code) and such message would communicate clearly the need to decide between them.
jsnell 6y ago
I think you're misunderstanding what was meant by "longer term compatibility". The issue isn't that the migration period was too short, it's that there was a such a big discontinuity in the compatibility in the first place. Python 3 provided no extra value at a high migration cost and painful library ecosystem issues. This is in contrast to typical programming language version migration, where breakages are either avoided entirely or are extremely localized. For example C++11 had some breaking changes compared to C++98. I don't know if I ever noticed them, but it didn't matter since C++11 added so much value that everyone wanted to migrated ASAP, and anyway there was no need to move the whole ecosystem at once. No matter how long the transition period was for Python 3, there was not going to be a good time to migrate. So most people would leave it until the very last minute, resent every hour of time spent on it, and sometimes put the option of rewriting in another language on the table.
- joshuamorton 6y ago
  > Python 3 provided no extra value at a high migration cost and painful library ecosystem issue I disagree with this. There was a lot of value add for specific (and relatively common) workloads. If you were doing unix automation you didn't gain much (but I argue this is because unix does unicode bad, not because python). But web development did, even if most of it wasn't obvious or was too soon to be obvious. As for c++ the effort the language goes to to maintain backwards compatibility has costs, both in terms of syntax and semantics. Those costs push people to rust etc. Much the same that migration to py3 pushes some people to go. It's difficult to say which is right without the ability to time travel.
syshum 6y ago
We have line of business code (not python) that still runs in production that was written over 20 years ago. Hell Larges parts of Windows is still code that is decades old... This "well you had plenty of time" shows just how much many modern / web developers do not understand Enterprise code, code that goes into manufacturing or other long running processes where "new" machines are 15 years old
- joshuamorton 6y ago
  I'm not clear what your point is. Much of the python3 code I use today was written 10 years ago (or more) and only barely had to be touched to work on 3. > other long running processes where "new" machines are 15 years old Then...pin to a 15 year old version and use that. No one is forcing you to upgrade.
- donor20 6y ago
  Web developers re-write their entire stack all the time. In a business with tons and tons (and tons) of little apps and services and command line tools etc, NO ONE wants to (or can) go through all this stuff to update it because someone decided the way unicode should be handled should change. The value gain to those 100's or little apps and utils is essentially zero. I do think a LOT of people got a lot better at making sure to lock configs down - it used to be you could basically ship the python file and as long as you were not doing something weird the system python / distro python would work fine. Now you really need to version pin everything, because python 3 was a nightmare for all the pip libraries and the knock on effects just showed up everywhere.
donor20 6y ago
Take a read here. Py3 was supposed to better - but in a LOT of use cases this better turned out to be "miserably slower". So you were asked to do a lot of work to get your code to run slower. File handling in the new unicode world was something like 2-3x SLOWER. This is not percent, something which took 3 minutes all of a sudden took NINE minutes because of the io module. URL parsers became a nightmare - dual implementations of codecs started poping up. https://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ https://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ For a "better" python, I didn't really start using it until 3.5 or so. Now it's much more pleasant, but at the key point of transition when everyone was going to check out the new thing, it was slow, put lots of extra bumps that appeared unnecessary to solve the problems that needed solving etc.
- joshuamorton 6y ago
  I'm not sure what your point is. You still had 12+ years of warning. You didn't need to migrate in 2010. I'd guess that the majority of application code migrated in the past 2 years, but that doesn't mean that you didn't have time to plan, and prepare. > File handling in the new unicode world was something like 2-3x SLOWER. This is not percent, something which took 3 minutes all of a sudden took NINE minutes because of the io module. Yes, unicode is slower. If you weren't using unicode you could and can still do all your processing in bytes mode.
  - donor20 6y ago
    That's not the way it worked. You couldn't migrate your code until your libraries had migrated. They didn't always want to migrate because their userbase was generally mostly on 2. This is what worries me - the lack of understanding of how broken these backward compat breaking changes are. Mercurial, built on python, took 10 years of work to get to python 3 - for basically no reward (they just need bytes and unicode is not super relevant to them) as just one example of MANY. Let me give you an example. in Python 2 you could use u'' for a unicode string. Perfect, I could update python 2 code to use this or b'' if I needed bytes so in the python 3 setting the right things could happen. The python developers literally TOOK THIS AWAY in python 3. So now, for no reason we can ever hope to understand, you couldn't write code that work work in 2 and 3 by using u'' and b''. This was the type of screw the developer in your face attitude that developers got. Let's be clear, library folks would need to write code that worked for python 2 and 3 for a long time. And instead of making this easy or at least reasonable, the python developers went out of their way to basically screw folks over here. Others will remember that the very reasonable formating approaches to bytes (yes, those are useful) was trashed in python 3, again for no seemingly good reason. % operator .format etc. WHY? I'm serious. "You had 12 years of warning" - hey how about python follows some other languages. Make the update compelling so folks are excited to move. Think about things that will make it easier instead of just pulling all these silly stunts. You couldn't practically move initially. Something as simple as doing u'' in python 2 that would alias properly in 3 - was a no go. This is what worries me about posts like yours, python developers have really no clue how stupid this type of backward compat breaking approach is if you have limited upside and go out of your way to make it hard to support both versions. It is critical that lesson be learned - but it seems hopeless. Anyways, go and others I think are going to make a reasonable run at this sort of utility language space with I think some stronger efforts around backward compatability. I think the next backwards incompatible change in python (python 4?) will probably see a much bigger migration off python.

ornxka 6y ago

>You had almost 15 years of warning from initial announcement to eol. Why should I have to do labor to fix things that already work?

CogitoCogito 6y ago
> Why should I have to do labor to fix things that already work? You don't right? Python 2 still works.
michaelmrose 6y ago
Maintaining python2 and python3 forever in perpetuity wouldn't be free either. Why should they provide free labor in perpetuity so that you need no provide any? In theory if there was sufficient need the entire community of python2 users could collectively fund said support but I don't see how they can demand it for free.
takeda 6y ago
You don't have to it's not like PSF made Python 2.7 stop working on January 1st 2020.
isbjorn16 6y ago
You don't need to, provided you're willing to also maintain a Python 2.x fork on your own instead, or willing to pay someone else to do it for you, or willing to risk no more patches to the interpreter. You do you, boo.

russfink 6y ago

Even a simple message in an exception statement, "you are running Python 3; could this be Python 2 code?"

joshuamorton 6y ago
I claim that this would have negative EV. Most exceptions aren't due to version mismatch. You could add a line for a very specific set of syntax errors, but those aren't very useful. Also having your new version suggest using the old version is counterproductive.
- Drdrdrq 6y ago
  Maybe... But there are two correct solutions (using an old version or upgrading the code) and such message would communicate clearly the need to decide between them.

jsnell 6y ago

I think you're misunderstanding what was meant by "longer term compatibility". The issue isn't that the migration period was too short, it's that there was a such a big discontinuity in the compatibility in the first place. Python 3 provided no extra value at a high migration cost and painful library ecosystem issues. This is in contrast to typical programming language version migration, where breakages are either avoided entirely or are extremely localized. For example C++11 had some breaking changes compared to C++98. I don't know if I ever noticed them, but it didn't matter since C++11 added so much value that everyone wanted to migrated ASAP, and anyway there was no need to move the whole ecosystem at once. No matter how long the transition period was for Python 3, there was not going to be a good time to migrate. So most people would leave it until the very last minute, resent every hour of time spent on it, and sometimes put the option of rewriting in another language on the table.

joshuamorton 6y ago
> Python 3 provided no extra value at a high migration cost and painful library ecosystem issue I disagree with this. There was a lot of value add for specific (and relatively common) workloads. If you were doing unix automation you didn't gain much (but I argue this is because unix does unicode bad, not because python). But web development did, even if most of it wasn't obvious or was too soon to be obvious. As for c++ the effort the language goes to to maintain backwards compatibility has costs, both in terms of syntax and semantics. Those costs push people to rust etc. Much the same that migration to py3 pushes some people to go. It's difficult to say which is right without the ability to time travel.

syshum 6y ago

We have line of business code (not python) that still runs in production that was written over 20 years ago. Hell Larges parts of Windows is still code that is decades old... This "well you had plenty of time" shows just how much many modern / web developers do not understand Enterprise code, code that goes into manufacturing or other long running processes where "new" machines are 15 years old

joshuamorton 6y ago
I'm not clear what your point is. Much of the python3 code I use today was written 10 years ago (or more) and only barely had to be touched to work on 3. > other long running processes where "new" machines are 15 years old Then...pin to a 15 year old version and use that. No one is forcing you to upgrade.
donor20 6y ago
Web developers re-write their entire stack all the time. In a business with tons and tons (and tons) of little apps and services and command line tools etc, NO ONE wants to (or can) go through all this stuff to update it because someone decided the way unicode should be handled should change. The value gain to those 100's or little apps and utils is essentially zero. I do think a LOT of people got a lot better at making sure to lock configs down - it used to be you could basically ship the python file and as long as you were not doing something weird the system python / distro python would work fine. Now you really need to version pin everything, because python 3 was a nightmare for all the pip libraries and the knock on effects just showed up everywhere.

donor20 6y ago

Take a read here. Py3 was supposed to better - but in a LOT of use cases this better turned out to be "miserably slower". So you were asked to do a lot of work to get your code to run slower. File handling in the new unicode world was something like 2-3x SLOWER. This is not percent, something which took 3 minutes all of a sudden took NINE minutes because of the io module. URL parsers became a nightmare - dual implementations of codecs started poping up. https://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ https://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ For a "better" python, I didn't really start using it until 3.5 or so. Now it's much more pleasant, but at the key point of transition when everyone was going to check out the new thing, it was slow, put lots of extra bumps that appeared unnecessary to solve the problems that needed solving etc.

joshuamorton 6y ago
I'm not sure what your point is. You still had 12+ years of warning. You didn't need to migrate in 2010. I'd guess that the majority of application code migrated in the past 2 years, but that doesn't mean that you didn't have time to plan, and prepare. > File handling in the new unicode world was something like 2-3x SLOWER. This is not percent, something which took 3 minutes all of a sudden took NINE minutes because of the io module. Yes, unicode is slower. If you weren't using unicode you could and can still do all your processing in bytes mode.
- donor20 6y ago
  That's not the way it worked. You couldn't migrate your code until your libraries had migrated. They didn't always want to migrate because their userbase was generally mostly on 2. This is what worries me - the lack of understanding of how broken these backward compat breaking changes are. Mercurial, built on python, took 10 years of work to get to python 3 - for basically no reward (they just need bytes and unicode is not super relevant to them) as just one example of MANY. Let me give you an example. in Python 2 you could use u'' for a unicode string. Perfect, I could update python 2 code to use this or b'' if I needed bytes so in the python 3 setting the right things could happen. The python developers literally TOOK THIS AWAY in python 3. So now, for no reason we can ever hope to understand, you couldn't write code that work work in 2 and 3 by using u'' and b''. This was the type of screw the developer in your face attitude that developers got. Let's be clear, library folks would need to write code that worked for python 2 and 3 for a long time. And instead of making this easy or at least reasonable, the python developers went out of their way to basically screw folks over here. Others will remember that the very reasonable formating approaches to bytes (yes, those are useful) was trashed in python 3, again for no seemingly good reason. % operator .format etc. WHY? I'm serious. "You had 12 years of warning" - hey how about python follows some other languages. Make the update compelling so folks are excited to move. Think about things that will make it easier instead of just pulling all these silly stunts. You couldn't practically move initially. Something as simple as doing u'' in python 2 that would alias properly in 3 - was a no go. This is what worries me about posts like yours, python developers have really no clue how stupid this type of backward compat breaking approach is if you have limited upside and go out of your way to make it hard to support both versions. It is critical that lesson be learned - but it seems hopeless. Anyways, go and others I think are going to make a reasonable run at this sort of utility language space with I think some stronger efforts around backward compatability. I think the next backwards incompatible change in python (python 4?) will probably see a much bigger migration off python.