20 ms·

Hindsight might very well be easy in this case, but I cannot think otherwise than finding the Python developers to have been ridiculously naïve in how they han

Hindsight might very well be easy in this case, but I cannot think otherwise than finding the Python developers to have been ridiculously naïve in how they handled this, and foolish to even begin it from the start. The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives. The very swarms of users that chanted “just upgrade” as if that not incur a significant cost also seemed ridiculously naïve to me, not understanding the real cost that large projects have by having to rewrite very extensive codebases and dealing the potential regressions that that might involve. Everything about the switch, from it's very conception, to it's execution, was handled in a veritably disastrous way by the team, that really did not seem to appreciate even a fraction of what obviously is involved with projects that have millions of lines of code and of course would rather not have to rewrite that all. This is why many projects such as Linux, Windows, Rust, Cobol, Fortran, C, and C++ take backwards compatibility quite serious. Serious enterprises do not like to invest in something if it mean that 10 years later they would have to rewrite their entire codebase again. Even on my home computer, I simply do not have the time to rewrite the many Python 2 scripts that have written over the years that run my computer. — it is cumbersome enough that once in a while part of my desktop stops functioning because my distribution removed a Python 2 library which I had relied upon as a system library that I now have to install as a user library but that was hitherto quite easily fixed. Do these men think that time is free?

brodie 6y ago
The Python core devs did not have the time or motivation to support the old codepaths in the CPython runtime, and the legacy code was getting in the way of a lot of longtime wants and needs for improving performance, runtime maintainability, language ergonomics, and the standard library. They also specifically increased the major revision number to signal their intent to move on from that legacy. But you kind of addressed your entire spiel: Hindsight is exceedingly easy. They didn't realize how inadequate their migration tooling was, or how very entrenched Python 2 is in various places. It's hard when you don't know what you don't know and you're highly motivated by hopeful aspirations.
- willis936 6y ago
  I don’t think hindsight can be claimed here. It was a decision that was not made from ignorance. The Python developers chose to sacrifice backwards compatibility. Other languages do not typically make such choices and if they do they make updating codebases relatively easy. Nothing about python versioning is easy. It’s a disaster and the key reason I do not start any projects in python.
  - ZuLuuuuuu 6y ago
    > Other languages do not typically make such choices and if they do they make updating codebases relatively easy. I want to understand what was so hard about porting code from Python 2 to 3. I ported a few tens of thousand lines of Python 2 code to Python 3 and it was pretty trivial. In my experience the only thing that made porting code hard was when a package you depended on was not ported to Python 3 yet. But maybe my experience does not reflect some other cases. Can you eloborate on what was so hard about porting code from Python 2 to 3?
    - OakNinja 6y ago
      The hardship of porting from 2 to 3 very much depends on how critical the software is. Porting 1000 lines of python 2 that deals with files encoded in various ways where it’s impossible to test all edge cases and where a failure might lead to huge liability charges is hard not because it’s hard to run 2to3 and do some random tests, but because you don’t know what you have missed. And still, a 300k lines of code project might be fine to just run 2to3 on and then find the bugs as you go. It’s a matter of context.
      - ZuLuuuuuu 6y ago
        There are certainly some cases where even the smallest backward incompatible change would cause serious problems on some systems. Thanks for giving an example, instead of just downvoting.
      - labawi 6y ago
hluska 6y ago
It’s the 21st century. Questions like “do these men think that time is free?” have no place in this century. Why not be accurate and say ‘people’? You chose to use a number of big words when simple ones would suffice. Why not take the same care in addressing people fairly?
- tsimionescu 6y ago
  For many non-native speakers, 'man' tends to be used as 'person' instead of 'male', probably because the translation of many common idioms involving 'man' uses a neutral word in their language. For example, when translating between English and Romanian, 'man' often gets translated to 'om', which doesn't imply a gender in modern Romanian. Even in English, 'man' is sometimes used without a gendered connotation. For example, if I say 'man is evil', I am unlikely to be referring to males, but rather people. Similarly, 'hey, man!' is not reserved for males.
  - yrimaxi 6y ago
    Singular man is more likely to be gender-neutral. Good example: “man is evil” clearly means people, since one would say “men are evil” if referring to males.
    - Blikkentrekker 6y ago
      “Men are evil.” can also refer to humans in general. I just searched for the phrase and it's about half split between either meaning from context inference. Yet, the meaning pertaining to the species is mostly from discussions by educated philosophers, and the other one are annoying identity politics arguments about why one's North American dating life is disappointing, — not exactly the audience I am ever interested in reaching, frankness be.
      - yrimaxi 6y ago
        Not terribly pertinent, then. One is more likely to fall into conversations about mundane topics with uneducated people than to stumble upon existential conversations with educated philosophers, even though the latter might produce a large corpus. One would also think that “man is evil” would be preferred by the erudite philosopher to the more ambigious “men are evil”, although one can never overestimate the fondness that an educated person might have towards pedantry, frankly.
LockAndLol 6y ago
Another typically ungrateful and entitled comment about opensource on HN. Color me surprised. > Do these men think that time is free? Do you think they have endless time to plan a migration with minute detail for every possible usecase? Users have about a decade to migrate their codebases and stop writing new projects in Python 2. Do you need another decade? Or are you personally going to take over the maintenance of the python2 runtime? Does anybody actually pay the core dev team for support? Do you? Does your company? Have they been coordinating all these years with the core devs and are unhappy with the result they paid for? I kinda doubt it. It would be really nice if people were just thankful for all the free stuff they got and built their enterprises on.
- sgt 6y ago
  Agreed, although I see our opinions are being heavily downvoted.
- Blikkentrekker 6y ago
  > Do you think they have endless time to plan a migration with minute detail for every possible usecase? My point is that for these small changes from 2 to 3, there should have never been a migration to begin with. It's not an accusation of lack of effort; it's an accusation of ignorance on their part. The migration has not only cost everyone else time and money; it has cost them time and money that was better spent elsewhere. It has been a net detriment to all parties, including them, because they severely underestimated the cost of rewriting software and dealing with the regressions it might lead to. I will damned well call a man foolish, for pointing a gun at his foot and getting shot in it, because he underestimated how easily the trigger would go off by accident, instead of being thankfully that he was willing to put in the effort to aim it at his foot.
  - paulryanrogers 6y ago
    You may be right or blinded by hindsight. Personally I'd rather see more breaking changes in languages like PHP that have a lot of baggage holding them back.
tinus_hn 6y ago
Really nice of them to spend their time supporting your case for free though. It’s open source, you can fund some program to keep supporting python 2.
- a1369209993 6y ago
  > It’s open source, you can fund some program to keep supporting python 2. No, actually, you can't - last time I checked, they were specifically threatening[0][1][others] to sue anyone who tried to continue developing Python for trademark infringement (despite that they are ones falsely using the trademark for something other what it got it's reputation from). 0: https://lwn.net/Articles/711092/ https://lwn.net/Articles/711092/ 1: https://github.com/naftaliharris/placeholder/issues/47 https://github.com/naftaliharris/placeholder/issues/47
  - tinus_hn 6y ago
    So they chose their own name and released under that. Here’s the Open Source Definition: https://opensource.org/osd https://opensource.org/osd > The license may require derived works to carry a different name or version number from the original software.
rtpg 6y ago
There are a billion blog posts about the python core developers acknowledging their mistakes and saying they would handle future changes much differently. This post might be true, but it's roughly 10 years late in terms of hitting the intended audience. Everyone gets this now, and "beating a dead horse" might be an understatement
- jacquesm 6y ago
  It's in response to something happening today. Some dead horses need a serious beating every now and then to remind people that they can resurrect if you're not careful. All of the lessons the python team did not put into practice were well known at the time, but they knew better and here we are. The day after tomorrow someone will make breaking changes to some API, framework, language or OS who still needs to learn this lesson, maybe we'll get to them in time.
  - vflagger 6y ago
    The lessons have not arrived at the current Python cabal. They just deprecated unittest and are seriously considering to break parts of the C-API again. For the people who work in the correct companies this will generate many billable hours for no gain. For others it will be a lot of unpaid work again. At this stage Python should be forked.
    - orf 6y ago
      Where has unittest been deprecated?
      - hwmartins 6y ago
        Probably a mixup with distutils, which has just been deprecated.
    - carapace 6y ago
      > At this stage Python should be forked. I seriously (I mean seriously) thought about forking Py2 (Tauthon is great BTW) but then I found out that PyPy has a Python2 mode and will for the foreseeable future. Just to be clear: PyPy runs Python 2 code, and always will. (As far as I know. Although it occurs to me that I have no idea what it's like if you're trying to work with the C API.) (Also I got into Prolog, but that's another story.)
Hendrikto 6y ago
> I simply do not have the time to rewrite the many Python 2 scripts that have written over the years that run my computer. In 12 years? You must have written some very extensive scripts.
- blandflakes 6y ago
  While I also find the timeline totally reasonable, I think most "I don't have the time" complaints are probably less about being able to finish it in time, and more about wanting to spend time doing something other than rewriting otherwise finished or stable code to satisfy a backwards-incompatible change.
ZuLuuuuuu 6y ago
> Serious enterprises do not like to invest in something if it mean that 10 years later they would have to rewrite their entire codebase again. Python 2 to Python 3 was nothing like rewriting an entire codebase. Most of the difficulty was if you depended on a package that only supported Python 2, other than that it was pretty easy to port a Python 2 codebase to Python 3. If you have millions of lines of code it might take more time understandably, but still it was nothing like rewriting a whole codebase.
raverbashing 6y ago
I've already tried running old C++ projects and every time something breaks, so it's not as clear cut as you make it to be Some things in Python 2 were not fixable by keeping it backwards compatible. Print as a statement? Sure. But strings/byte arrays, no way. Of course they could have made the Py2 implementation less broken and less stupid (yes please do use ASCII as the default, ignore the existence of unicode, be trigger-happy about errors, etc)
- flohofwoe 6y ago
  The whole string/bytearray disaster could have been prevented if strings would always be UTF-8 encoded. That way strings and bytearrays can continue to be different views on the same data. The great divide between byte- and string-data was completely pointless, especially in 2008 when python3 was started because by that time UTF-8 was already firmly established for at least a decade (it would be an excusable design fault only in the 1990's).
  - jeroenhd 6y ago
    > by that time UTF-8 was already firmly established for at least a decade For text files, maybe, but various APIs like the Window API and the Java String API still use UTF-16. UTF-8 dependence is also a major pain for many where the local character set conflicts with UTF-8. For example, there's still a lot of Japanese files out there in SJIS that need to be decoded accordingly. The country of Myanmar officially switched to unicode less than two years ago so if you still need to operate on older data, you're going to need to support their old character set. UTF-8 as a fixed encoding only works if you manage to write mappers from and to alternative character set for practically any language outside US English. Instead of breaking compatibility with most libraries, python3 would have broken compatibility with most libraries and a few countries instead. Just like the rest of the world has to deal with three countries refusing to switch to metric, python3 needed to deal with countries refusing to switch to UTF8.
    - raverbashing 6y ago
      They could have made the Windows version UTF-16 by default for example. Or they could have fixed setdefaultencoding or give us a way to set the default encoding https://stackoverflow.com/questions/3828723/why-should-we-not-use-sys-setdefaultencodingutf-8-in-a-py-script https://stackoverflow.com/questions/3828723/why-should-we-no... I don't buy the "discouragement" part there, if anything they could have made it mandatory or at least it set it to UTF-8 > For example, there's still a lot of Japanese files out there in SJIS that need to be decoded accordingly. Yes but you would have to work on those cases anyway and ASCII would have made it blow anyway. But convert it to UTF-8/16 and it works. EDIT: the reason is apparently that "(setdefaultencoding) will allow these to work for me, but won't necessarily work for people who don't use UTF-8. The default of ASCII ensures that assumptions of encoding are not baked into code" Really. I can't explain my anger at how this is such an idiotic excuse. Yes, your program will fail if you use Latin-1 encoding, duh. Configure your environment correctly and it will work. Sounds like the kind of pedantry that made Guido quit over the walrus operator
orf 6y ago
> The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives. There where large changes to fundamental parts of the type system, as well as core types. Pretending this isn’t the case belays ignorance or at the very least cherry picking. How would you have handled the string/bytes split in a way that’s backwards compatible? Or the removal of old-style classes?
- ktpsns 6y ago
  I think some modular approach could have solved the incompatiblity issue, such as "from future import ...". Shorthands could have been invented to define everything in a single line. Perl5 has similar flags ("use strict"), and Racket brings it even further to define the whole fucking language of the rest of the file ("#lang racket/gui"). Having the language being choosable by the user is against the "zen of python", I guess. In other words: Such an attemp does not feel "pythonic".
  - orf 6y ago
    For some syntactical sugar, like print-function, sure. But there are more fundamental changes that couldn’t be papered over.
    - jamiesonbecker 6y ago
      Fundamental changes shouldn't have been papered over by calling the new language Python, as it was a fundamentally different language at that point.
      - orf 6y ago
        No, it’s the same language but with different semantics around a specific type. That’s not a different language and code can co-exist with a bit of thought.
      - JasonFruit 6y ago
        Every language goes through this at some point in its development: flaws that limit future development have to be fixed. Should every language rename itself and split its community at that point? That seems like an extreme response to a common problem.
TomSwirly 6y ago
> The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives. There were serious issues in Python 2 that could not be fixed in any backward compatible way, and would have made further progress forward impossible. It wasn't done lightly and a lot of smart people thought about it for a long time. --- And your old Python 2 scripts will continue to work forever, so I'm not quite sure what your beef is.
bildung 6y ago
> The very swarms of users that chanted “just upgrade” as if that not incur a significant cost also seemed ridiculously naïve to me, not understanding the real cost that large projects have by having to rewrite very extensive codebases and dealing the potential regressions that that might involve. And yet we haven't heard of this being an actual, real problem, or are there any high profile examples? I had to migrate multiple small projects (~10k loc) myself. That should be the typical use case for python (power law etc.) The whole thing took about half an hour per 1000 loc, and I had more than 10 years to plan it.
pyrale 6y ago
> Do these men think that time is free? Written by someone that, for some reason, did not decide to maintain their own fork of python2. If time isn't free, why is it expected from maintainers to support other companies' lifestyle with their own time?
- Chris2048 6y ago
  It isn't - just hand it off. If you don't like the laws, are you a hypocrite for not starting your own country? Arguments in this thread seem to miss a discrepancy: "We don't want to support py2, and so why should we? Our time isn't free and we do what we want!" "We know you don't want to migrate your py2 code, but you have to." Forks aren't easy, especially when you get no support from the "official" python-2 maintainers. At the very least, a fork would not own the name. Here's a question - why isn't python-3 a fork of python? Answer: because forks are hard, and the devs wanted to keep all the momentum/resources of python-2.
  - pyrale 6y ago
    The fork comment is not meant to be a realistic suggestion, it just points out that there is work needed to maintain compatibility. The thing is, you can't both complain about the time it takes to migrate your project _and_ expect maintainers to spend an incommensurate amount of time maintaining suff for you, free of charge. I understand that some people and companies are now caught between a rock and a hard place right now. But honestly, that rock has been coming for 12 years now, and the alternative is to put other people in that situation.
    - Chris2048 6y ago
      Sure, but the assumption is py3 devs do the work in order to dismiss the idea and suggest people are entitled. py3 devs don't need to do the work, they just need to hand it off. > The thing is, you can't both.. Yes you can, if "maintaining" is handing it off, as opposed to the straw man of forcing py3 devs to do it. Why do the gatekeepers only allow for themselves to do the work? > that rock has been coming for 12 years notice is not consent. > the alternative is to put other people in that situation 12 years is enough time to hand off to people who are happy to maintain py2. But there was no choice given.
Chris2048 6y ago
Progress needs to be made, and sometimes dropping support for stuff you no longer want to spend time supporting makes sense. That said, I still think situation is mishandled for this reason: py3 is basically another language, similar to py2. Calling it py3 is an exercise in marketing - instead of creating a new language to compete with py2 (along with all similar languages e.g. Julia) the existing py2 community was leveraged/shamed* into supporting the new thing, and most importantly, py2 was killed by it's maintainers (rather than handed off) so it couldn't compete with py3, and so that users would be forced to move somewhere else - py3 being the easiest. If it had properly been a new language, they could have taken more liberties (compat breaking) to fix issues, like a single official package manager. And migration to py3 would have been more by consent, than by force. * https://python3wos.appspot.com/ https://python3wos.appspot.com/
- carapace 6y ago
  Very much this. It's a separate language that, if it hadn't been pushed by BDFL and co., if it had appeared as an independent project (like e.g. Stackless Python or something), would have had to live or die on its own merits. - - - - An additional aspect that I see as an old Python user is the "poisoning of the well" of the inclusive and welcoming spirit of the community. We (I'm speaking as a Pythonista here) have had problems with this in the past (remember how grouchy effbot could be? He's a sweet person IRL though.) We made great progress and got a lot of acceptance in the educational and academic worlds. Now just read this very thread and you'll find so many people making curt dismissive comments to folks who aren't on board with Python 3. I still love and respect GvR (I once, with his permission, gave him a hug!) even though I think he messed up with this 2->3 business (and in any event, the drama around language innovation eventually pushed him to resign, as we all know.) He's a human being. And a pretty good one. I guess what I'm trying to say is Python 3 won. Let us (all of us) be gracious about it.
wirrbel 6y ago
I have migrated tons of Python codebases from 2 to 3, i guess starting with the release of Python3.4 which was when Python3 reached a kind of production readiness (and also had gained enough trust and IIRC it had also reestablished compatibility in some parts). I think the incompatibilities between Python 2 and Python 3 fell into two categories 1. trivial and totally avoidable API changes by the Python developers ( like `iteritems()` being renamed to `items()` and the Python2-`items` being removed from the language). The bet on the Python-dev side was that `2to3` would take care of that and in this they totally underestimated that libraries couldn't and wouldn't just make a python3 migration in lockstep with the primary python release. 2. Change to unicode-strings by default with a clear distinction between unicode-strings and byte-buffers for all data encoded in any other fashion. Most people on Python3 nowadays won't actually know how beneficial Change no. 2 was overall for the health of the Python ecosystem and the stability of their code bases. But it also was the tricky part of the migration for some code bases that would do a lot of string / file content plumbing like mercurial as a prominent example). Change no. 1. was a PITA and a lot could have been avoided, but it wasn't a huge problem. The huge problem for the ecosystem was the unicode change, but I don't think anyone questions its usefulness (except for Armin Ronacher maybe, who is the most prominent voice with a dislike for that).
- josephorjoe 6y ago
  The string change (rightly) is always brought up, but the one that has always amazed me is they changed how division works. Whenever I show this to people they are (rightly) horrified. ~ $ python Python 2.7.16 >>> 3/2 1 ~ $ python3 Python 3.7.7 >>> 3/2 1.5
  - wirrbel 6y ago
    Well, breaking change, but harmless in most instances, the other way around would be more harmful. Also that was I think a „from future import“ option so you could enable it while on python 2.7 on a per file basis
- ehutch79 6y ago
  I am so thankful for that unicode change. 2.x's unicode was a problem for me.

brodie 6y ago

The Python core devs did not have the time or motivation to support the old codepaths in the CPython runtime, and the legacy code was getting in the way of a lot of longtime wants and needs for improving performance, runtime maintainability, language ergonomics, and the standard library. They also specifically increased the major revision number to signal their intent to move on from that legacy. But you kind of addressed your entire spiel: Hindsight is exceedingly easy. They didn't realize how inadequate their migration tooling was, or how very entrenched Python 2 is in various places. It's hard when you don't know what you don't know and you're highly motivated by hopeful aspirations.

willis936 6y ago
I don’t think hindsight can be claimed here. It was a decision that was not made from ignorance. The Python developers chose to sacrifice backwards compatibility. Other languages do not typically make such choices and if they do they make updating codebases relatively easy. Nothing about python versioning is easy. It’s a disaster and the key reason I do not start any projects in python.
- ZuLuuuuuu 6y ago
  > Other languages do not typically make such choices and if they do they make updating codebases relatively easy. I want to understand what was so hard about porting code from Python 2 to 3. I ported a few tens of thousand lines of Python 2 code to Python 3 and it was pretty trivial. In my experience the only thing that made porting code hard was when a package you depended on was not ported to Python 3 yet. But maybe my experience does not reflect some other cases. Can you eloborate on what was so hard about porting code from Python 2 to 3?
  - OakNinja 6y ago
    The hardship of porting from 2 to 3 very much depends on how critical the software is. Porting 1000 lines of python 2 that deals with files encoded in various ways where it’s impossible to test all edge cases and where a failure might lead to huge liability charges is hard not because it’s hard to run 2to3 and do some random tests, but because you don’t know what you have missed. And still, a 300k lines of code project might be fine to just run 2to3 on and then find the bugs as you go. It’s a matter of context.
    - ZuLuuuuuu 6y ago
      There are certainly some cases where even the smallest backward incompatible change would cause serious problems on some systems. Thanks for giving an example, instead of just downvoting.
    - labawi 6y ago

hluska 6y ago

It’s the 21st century. Questions like “do these men think that time is free?” have no place in this century. Why not be accurate and say ‘people’? You chose to use a number of big words when simple ones would suffice. Why not take the same care in addressing people fairly?

tsimionescu 6y ago
For many non-native speakers, 'man' tends to be used as 'person' instead of 'male', probably because the translation of many common idioms involving 'man' uses a neutral word in their language. For example, when translating between English and Romanian, 'man' often gets translated to 'om', which doesn't imply a gender in modern Romanian. Even in English, 'man' is sometimes used without a gendered connotation. For example, if I say 'man is evil', I am unlikely to be referring to males, but rather people. Similarly, 'hey, man!' is not reserved for males.
- yrimaxi 6y ago
  Singular man is more likely to be gender-neutral. Good example: “man is evil” clearly means people, since one would say “men are evil” if referring to males.
  - Blikkentrekker 6y ago
    “Men are evil.” can also refer to humans in general. I just searched for the phrase and it's about half split between either meaning from context inference. Yet, the meaning pertaining to the species is mostly from discussions by educated philosophers, and the other one are annoying identity politics arguments about why one's North American dating life is disappointing, — not exactly the audience I am ever interested in reaching, frankness be.
    - yrimaxi 6y ago
      Not terribly pertinent, then. One is more likely to fall into conversations about mundane topics with uneducated people than to stumble upon existential conversations with educated philosophers, even though the latter might produce a large corpus. One would also think that “man is evil” would be preferred by the erudite philosopher to the more ambigious “men are evil”, although one can never overestimate the fondness that an educated person might have towards pedantry, frankly.

LockAndLol 6y ago

Another typically ungrateful and entitled comment about opensource on HN. Color me surprised. > Do these men think that time is free? Do you think they have endless time to plan a migration with minute detail for every possible usecase? Users have about a decade to migrate their codebases and stop writing new projects in Python 2. Do you need another decade? Or are you personally going to take over the maintenance of the python2 runtime? Does anybody actually pay the core dev team for support? Do you? Does your company? Have they been coordinating all these years with the core devs and are unhappy with the result they paid for? I kinda doubt it. It would be really nice if people were just thankful for all the free stuff they got and built their enterprises on.

sgt 6y ago
Agreed, although I see our opinions are being heavily downvoted.
Blikkentrekker 6y ago
> Do you think they have endless time to plan a migration with minute detail for every possible usecase? My point is that for these small changes from 2 to 3, there should have never been a migration to begin with. It's not an accusation of lack of effort; it's an accusation of ignorance on their part. The migration has not only cost everyone else time and money; it has cost them time and money that was better spent elsewhere. It has been a net detriment to all parties, including them, because they severely underestimated the cost of rewriting software and dealing with the regressions it might lead to. I will damned well call a man foolish, for pointing a gun at his foot and getting shot in it, because he underestimated how easily the trigger would go off by accident, instead of being thankfully that he was willing to put in the effort to aim it at his foot.
- paulryanrogers 6y ago
  You may be right or blinded by hindsight. Personally I'd rather see more breaking changes in languages like PHP that have a lot of baggage holding them back.

tinus_hn 6y ago

Really nice of them to spend their time supporting your case for free though. It’s open source, you can fund some program to keep supporting python 2.

a1369209993 6y ago
> It’s open source, you can fund some program to keep supporting python 2. No, actually, you can't - last time I checked, they were specifically threatening[0][1][others] to sue anyone who tried to continue developing Python for trademark infringement (despite that they are ones falsely using the trademark for something other what it got it's reputation from). 0: https://lwn.net/Articles/711092/ https://lwn.net/Articles/711092/ 1: https://github.com/naftaliharris/placeholder/issues/47 https://github.com/naftaliharris/placeholder/issues/47
- tinus_hn 6y ago
  So they chose their own name and released under that. Here’s the Open Source Definition: https://opensource.org/osd https://opensource.org/osd > The license may require derived works to carry a different name or version number from the original software.

rtpg 6y ago

There are a billion blog posts about the python core developers acknowledging their mistakes and saying they would handle future changes much differently. This post might be true, but it's roughly 10 years late in terms of hitting the intended audience. Everyone gets this now, and "beating a dead horse" might be an understatement

jacquesm 6y ago
It's in response to something happening today. Some dead horses need a serious beating every now and then to remind people that they can resurrect if you're not careful. All of the lessons the python team did not put into practice were well known at the time, but they knew better and here we are. The day after tomorrow someone will make breaking changes to some API, framework, language or OS who still needs to learn this lesson, maybe we'll get to them in time.
- vflagger 6y ago
  The lessons have not arrived at the current Python cabal. They just deprecated unittest and are seriously considering to break parts of the C-API again. For the people who work in the correct companies this will generate many billable hours for no gain. For others it will be a lot of unpaid work again. At this stage Python should be forked.
  - orf 6y ago
    Where has unittest been deprecated?
    - hwmartins 6y ago
      Probably a mixup with distutils, which has just been deprecated.
  - carapace 6y ago
    > At this stage Python should be forked. I seriously (I mean seriously) thought about forking Py2 (Tauthon is great BTW) but then I found out that PyPy has a Python2 mode and will for the foreseeable future. Just to be clear: PyPy runs Python 2 code, and always will. (As far as I know. Although it occurs to me that I have no idea what it's like if you're trying to work with the C API.) (Also I got into Prolog, but that's another story.)

Hendrikto 6y ago

> I simply do not have the time to rewrite the many Python 2 scripts that have written over the years that run my computer. In 12 years? You must have written some very extensive scripts.

blandflakes 6y ago
While I also find the timeline totally reasonable, I think most "I don't have the time" complaints are probably less about being able to finish it in time, and more about wanting to spend time doing something other than rewriting otherwise finished or stable code to satisfy a backwards-incompatible change.

ZuLuuuuuu 6y ago

> Serious enterprises do not like to invest in something if it mean that 10 years later they would have to rewrite their entire codebase again. Python 2 to Python 3 was nothing like rewriting an entire codebase. Most of the difficulty was if you depended on a package that only supported Python 2, other than that it was pretty easy to port a Python 2 codebase to Python 3. If you have millions of lines of code it might take more time understandably, but still it was nothing like rewriting a whole codebase.

raverbashing 6y ago

I've already tried running old C++ projects and every time something breaks, so it's not as clear cut as you make it to be Some things in Python 2 were not fixable by keeping it backwards compatible. Print as a statement? Sure. But strings/byte arrays, no way. Of course they could have made the Py2 implementation less broken and less stupid (yes please do use ASCII as the default, ignore the existence of unicode, be trigger-happy about errors, etc)

flohofwoe 6y ago
The whole string/bytearray disaster could have been prevented if strings would always be UTF-8 encoded. That way strings and bytearrays can continue to be different views on the same data. The great divide between byte- and string-data was completely pointless, especially in 2008 when python3 was started because by that time UTF-8 was already firmly established for at least a decade (it would be an excusable design fault only in the 1990's).
- jeroenhd 6y ago
  > by that time UTF-8 was already firmly established for at least a decade For text files, maybe, but various APIs like the Window API and the Java String API still use UTF-16. UTF-8 dependence is also a major pain for many where the local character set conflicts with UTF-8. For example, there's still a lot of Japanese files out there in SJIS that need to be decoded accordingly. The country of Myanmar officially switched to unicode less than two years ago so if you still need to operate on older data, you're going to need to support their old character set. UTF-8 as a fixed encoding only works if you manage to write mappers from and to alternative character set for practically any language outside US English. Instead of breaking compatibility with most libraries, python3 would have broken compatibility with most libraries and a few countries instead. Just like the rest of the world has to deal with three countries refusing to switch to metric, python3 needed to deal with countries refusing to switch to UTF8.
  - raverbashing 6y ago
    They could have made the Windows version UTF-16 by default for example. Or they could have fixed setdefaultencoding or give us a way to set the default encoding https://stackoverflow.com/questions/3828723/why-should-we-not-use-sys-setdefaultencodingutf-8-in-a-py-script https://stackoverflow.com/questions/3828723/why-should-we-no... I don't buy the "discouragement" part there, if anything they could have made it mandatory or at least it set it to UTF-8 > For example, there's still a lot of Japanese files out there in SJIS that need to be decoded accordingly. Yes but you would have to work on those cases anyway and ASCII would have made it blow anyway. But convert it to UTF-8/16 and it works. EDIT: the reason is apparently that "(setdefaultencoding) will allow these to work for me, but won't necessarily work for people who don't use UTF-8. The default of ASCII ensures that assumptions of encoding are not baked into code" Really. I can't explain my anger at how this is such an idiotic excuse. Yes, your program will fail if you use Latin-1 encoding, duh. Configure your environment correctly and it will work. Sounds like the kind of pedantry that made Guido quit over the walrus operator

orf 6y ago

> The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives. There where large changes to fundamental parts of the type system, as well as core types. Pretending this isn’t the case belays ignorance or at the very least cherry picking. How would you have handled the string/bytes split in a way that’s backwards compatible? Or the removal of old-style classes?

ktpsns 6y ago
I think some modular approach could have solved the incompatiblity issue, such as "from future import ...". Shorthands could have been invented to define everything in a single line. Perl5 has similar flags ("use strict"), and Racket brings it even further to define the whole fucking language of the rest of the file ("#lang racket/gui"). Having the language being choosable by the user is against the "zen of python", I guess. In other words: Such an attemp does not feel "pythonic".
- orf 6y ago
  For some syntactical sugar, like print-function, sure. But there are more fundamental changes that couldn’t be papered over.
  - jamiesonbecker 6y ago
    Fundamental changes shouldn't have been papered over by calling the new language Python, as it was a fundamentally different language at that point.
    - orf 6y ago
      No, it’s the same language but with different semantics around a specific type. That’s not a different language and code can co-exist with a bit of thought.
    - JasonFruit 6y ago
      Every language goes through this at some point in its development: flaws that limit future development have to be fixed. Should every language rename itself and split its community at that point? That seems like an extreme response to a common problem.

TomSwirly 6y ago

> The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives. There were serious issues in Python 2 that could not be fixed in any backward compatible way, and would have made further progress forward impossible. It wasn't done lightly and a lot of smart people thought about it for a long time. --- And your old Python 2 scripts will continue to work forever, so I'm not quite sure what your beef is.

bildung 6y ago

> The very swarms of users that chanted “just upgrade” as if that not incur a significant cost also seemed ridiculously naïve to me, not understanding the real cost that large projects have by having to rewrite very extensive codebases and dealing the potential regressions that that might involve. And yet we haven't heard of this being an actual, real problem, or are there any high profile examples? I had to migrate multiple small projects (~10k loc) myself. That should be the typical use case for python (power law etc.) The whole thing took about half an hour per 1000 loc, and I had more than 10 years to plan it.

pyrale 6y ago

> Do these men think that time is free? Written by someone that, for some reason, did not decide to maintain their own fork of python2. If time isn't free, why is it expected from maintainers to support other companies' lifestyle with their own time?

Chris2048 6y ago
It isn't - just hand it off. If you don't like the laws, are you a hypocrite for not starting your own country? Arguments in this thread seem to miss a discrepancy: "We don't want to support py2, and so why should we? Our time isn't free and we do what we want!" "We know you don't want to migrate your py2 code, but you have to." Forks aren't easy, especially when you get no support from the "official" python-2 maintainers. At the very least, a fork would not own the name. Here's a question - why isn't python-3 a fork of python? Answer: because forks are hard, and the devs wanted to keep all the momentum/resources of python-2.
- pyrale 6y ago
  The fork comment is not meant to be a realistic suggestion, it just points out that there is work needed to maintain compatibility. The thing is, you can't both complain about the time it takes to migrate your project _and_ expect maintainers to spend an incommensurate amount of time maintaining suff for you, free of charge. I understand that some people and companies are now caught between a rock and a hard place right now. But honestly, that rock has been coming for 12 years now, and the alternative is to put other people in that situation.
  - Chris2048 6y ago
    Sure, but the assumption is py3 devs do the work in order to dismiss the idea and suggest people are entitled. py3 devs don't need to do the work, they just need to hand it off. > The thing is, you can't both.. Yes you can, if "maintaining" is handing it off, as opposed to the straw man of forcing py3 devs to do it. Why do the gatekeepers only allow for themselves to do the work? > that rock has been coming for 12 years notice is not consent. > the alternative is to put other people in that situation 12 years is enough time to hand off to people who are happy to maintain py2. But there was no choice given.

Chris2048 6y ago

Progress needs to be made, and sometimes dropping support for stuff you no longer want to spend time supporting makes sense. That said, I still think situation is mishandled for this reason: py3 is basically another language, similar to py2. Calling it py3 is an exercise in marketing - instead of creating a new language to compete with py2 (along with all similar languages e.g. Julia) the existing py2 community was leveraged/shamed* into supporting the new thing, and most importantly, py2 was killed by it's maintainers (rather than handed off) so it couldn't compete with py3, and so that users would be forced to move somewhere else - py3 being the easiest. If it had properly been a new language, they could have taken more liberties (compat breaking) to fix issues, like a single official package manager. And migration to py3 would have been more by consent, than by force. * https://python3wos.appspot.com/ https://python3wos.appspot.com/

carapace 6y ago
Very much this. It's a separate language that, if it hadn't been pushed by BDFL and co., if it had appeared as an independent project (like e.g. Stackless Python or something), would have had to live or die on its own merits. - - - - An additional aspect that I see as an old Python user is the "poisoning of the well" of the inclusive and welcoming spirit of the community. We (I'm speaking as a Pythonista here) have had problems with this in the past (remember how grouchy effbot could be? He's a sweet person IRL though.) We made great progress and got a lot of acceptance in the educational and academic worlds. Now just read this very thread and you'll find so many people making curt dismissive comments to folks who aren't on board with Python 3. I still love and respect GvR (I once, with his permission, gave him a hug!) even though I think he messed up with this 2->3 business (and in any event, the drama around language innovation eventually pushed him to resign, as we all know.) He's a human being. And a pretty good one. I guess what I'm trying to say is Python 3 won. Let us (all of us) be gracious about it.

wirrbel 6y ago

I have migrated tons of Python codebases from 2 to 3, i guess starting with the release of Python3.4 which was when Python3 reached a kind of production readiness (and also had gained enough trust and IIRC it had also reestablished compatibility in some parts). I think the incompatibilities between Python 2 and Python 3 fell into two categories 1. trivial and totally avoidable API changes by the Python developers ( like `iteritems()` being renamed to `items()` and the Python2-`items` being removed from the language). The bet on the Python-dev side was that `2to3` would take care of that and in this they totally underestimated that libraries couldn't and wouldn't just make a python3 migration in lockstep with the primary python release. 2. Change to unicode-strings by default with a clear distinction between unicode-strings and byte-buffers for all data encoded in any other fashion. Most people on Python3 nowadays won't actually know how beneficial Change no. 2 was overall for the health of the Python ecosystem and the stability of their code bases. But it also was the tricky part of the migration for some code bases that would do a lot of string / file content plumbing like mercurial as a prominent example). Change no. 1. was a PITA and a lot could have been avoided, but it wasn't a huge problem. The huge problem for the ecosystem was the unicode change, but I don't think anyone questions its usefulness (except for Armin Ronacher maybe, who is the most prominent voice with a dislike for that).

josephorjoe 6y ago
The string change (rightly) is always brought up, but the one that has always amazed me is they changed how division works. Whenever I show this to people they are (rightly) horrified. ~ $ python Python 2.7.16 >>> 3/2 1 ~ $ python3 Python 3.7.7 >>> 3/2 1.5
- wirrbel 6y ago
  Well, breaking change, but harmless in most instances, the other way around would be more harmful. Also that was I think a „from future import“ option so you could enable it while on python 2.7 on a per file basis
ehutch79 6y ago
I am so thankful for that unicode change. 2.x's unicode was a problem for me.