5 ms·

Agreed completely. There were so many routes forward that didn't involve breaking everything but still would have allowed fewer unicode bugs (maybe). And they

Agreed completely. There were so many routes forward that didn't involve breaking everything but still would have allowed fewer unicode bugs (maybe). 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 cases (a lot of internet protocols, headers etc still ASCII). What is nuts to think about - if tweaking some unicode handling is worth creating an incompatible version, what happens when some random python developer has another itch to scratch that they consider so important it is worth break a language over. The idea that these types of fixes require breaking compatibility is absolutely insane if you want to address a larger / longer term market. Complain all you want about Microsoft, C etc. Even go of all languages (because google has an otherwise terrible rep in this area!!). But some of these languages and companies really do seem to be able to deliver or intend to deliver longer term compatibility. When businesses and lifetimes are measured in decades (not months) it is VERY nice to build on stuff that has longer support horizons.

joshuamorton 6y ago
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.
theonemind 6y ago
I think Perl 5 (despite the much bigger Perl 6 fork) used a language pragma for unicode. When Java introduced generics, they had to use type erasure. It does seem like if you put in some effort and do some decidedly unaesthetic things, you can bolt on and backport a lot. No developer dreams of maintaining dirty hacks at scale, though.
- lizmat 6y ago
  Please note that Perl 6 did not start out as a fork, but over the years effectively was considered to be one. Which is why it changed its name to Raku (https://raku.org https://raku.org using the #rakulang tag on social media).
Shared404 6y ago
> When businesses and lifetimes are measured in decades (not months) it is VERY nice to build on stuff that has longer support horizons. Indeed. I'm in the process of writing some simple web stuff. I considered python, but decided against it because I'm doing this for free, and don't want to be asked to come back and fix it in a decade because "Python 4.6 needed a feature, and it'll break compatibility with Python 3" Yes, they could still just run it with Python 3, but do I really want to go through the effort of explaining how to configure that instead of just handing over a working binary?
- xapata 6y ago
  Why would you worry about that for Python? The community learned their lesson. I'd worry more about other language maintainers who haven't had the learning experience.
  - Shared404 6y ago
    Because with Python the possibility is still there. With C/Rust/Go, it's simple to statically compile and remove the possibility of that type of issue. It's not a program that will be running on a server, so I'm not really concerned about security fixes/updates to libraries.
    - xapata 6y ago
      Uh, just use the old interpreter. Same situation.
      - Shared404 6y ago
        And then the distro they are using stops shipping Python 3 by default because "No one should be using that anymore.". While I could bundle python with the program, that's getting to be more hassle then it really seems like it's worth. In addition, I'm not particularly comfortable with configuring python, so there's a non negligible chance I'd screw that up and be in the same position. It's not that it's impossible for Python to work in this situation, it's that me doing it is a bad idea. I'm sorry if my original comment implied otherwise.
BlueTemplar 6y ago
Internally, Python 3 still doesn't use Unicode, and it's pretty arbitrary whether a specific unicode sign is allowed as a variable name.
takeda 6y ago
What you're talking about Have you tried to run VB6 code in latest VB? Things are getting broken all the time, the major mistake IMO what PSF did is giving 10 years to migrate code. Everyone waited to middle of 2019 when they actually started to migrate and the 10 years only allowed to created FUD.
BuckRogers 6y ago
I used Python for a while years ago and asked a core developer about this, he said they’re not paid for support of that nature and to talk to Red Hat. For them it’s just a fun project, no matter who (foolishly?) built a product on it. They’ve made it out to look like a toy language, but it’s taken seriously. So I went with C# instead. I’d choose it again over Python.
- freedomben 6y ago
  Did you end up talking to Red hat? I'm curious about how much "support" they'll provide. I can't imagine anything other than back porting security fixes, but even then it seems like they'd be pretty limited.

joshuamorton 6y ago

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.

theonemind 6y ago

I think Perl 5 (despite the much bigger Perl 6 fork) used a language pragma for unicode. When Java introduced generics, they had to use type erasure. It does seem like if you put in some effort and do some decidedly unaesthetic things, you can bolt on and backport a lot. No developer dreams of maintaining dirty hacks at scale, though.

lizmat 6y ago
Please note that Perl 6 did not start out as a fork, but over the years effectively was considered to be one. Which is why it changed its name to Raku (https://raku.org https://raku.org using the #rakulang tag on social media).

Shared404 6y ago

> When businesses and lifetimes are measured in decades (not months) it is VERY nice to build on stuff that has longer support horizons. Indeed. I'm in the process of writing some simple web stuff. I considered python, but decided against it because I'm doing this for free, and don't want to be asked to come back and fix it in a decade because "Python 4.6 needed a feature, and it'll break compatibility with Python 3" Yes, they could still just run it with Python 3, but do I really want to go through the effort of explaining how to configure that instead of just handing over a working binary?

xapata 6y ago
Why would you worry about that for Python? The community learned their lesson. I'd worry more about other language maintainers who haven't had the learning experience.
- Shared404 6y ago
  Because with Python the possibility is still there. With C/Rust/Go, it's simple to statically compile and remove the possibility of that type of issue. It's not a program that will be running on a server, so I'm not really concerned about security fixes/updates to libraries.
  - xapata 6y ago
    Uh, just use the old interpreter. Same situation.
    - Shared404 6y ago
      And then the distro they are using stops shipping Python 3 by default because "No one should be using that anymore.". While I could bundle python with the program, that's getting to be more hassle then it really seems like it's worth. In addition, I'm not particularly comfortable with configuring python, so there's a non negligible chance I'd screw that up and be in the same position. It's not that it's impossible for Python to work in this situation, it's that me doing it is a bad idea. I'm sorry if my original comment implied otherwise.

BlueTemplar 6y ago

Internally, Python 3 still doesn't use Unicode, and it's pretty arbitrary whether a specific unicode sign is allowed as a variable name.

takeda 6y ago

What you're talking about Have you tried to run VB6 code in latest VB? Things are getting broken all the time, the major mistake IMO what PSF did is giving 10 years to migrate code. Everyone waited to middle of 2019 when they actually started to migrate and the 10 years only allowed to created FUD.

BuckRogers 6y ago

I used Python for a while years ago and asked a core developer about this, he said they’re not paid for support of that nature and to talk to Red Hat. For them it’s just a fun project, no matter who (foolishly?) built a product on it. They’ve made it out to look like a toy language, but it’s taken seriously. So I went with C# instead. I’d choose it again over Python.

freedomben 6y ago
Did you end up talking to Red hat? I'm curious about how much "support" they'll provide. I can't imagine anything other than back porting security fixes, but even then it seems like they'd be pretty limited.