10 ms·

print "goodbye, sweet prince" I've been slowly porting a lot of my legacy code from 2 to 3 on an as-needed basis, there's a few bits though that are just too h

print "goodbye, sweet prince" I've been slowly porting a lot of my legacy code from 2 to 3 on an as-needed basis, there's a few bits though that are just too huge/crusty/etc that they will never get ported.

bmitc 4y ago
Doesn't this say something about the language if it's been so difficult for people to migrate from 2 to 3? Yes, it was a major version change, but it doesn't bode well for arguments that Python is a good language to do long-term, maintainable, and large-scale development. Sure, now things are "settled" with 3, but Python continues to get more features. It just doesn't look good for the language if even doing a language version migration was a literal brick wall for so much of the community.
- jacquesm 4y ago
  Let me be blunt here: Python sucks, but that's at the level of 'programming languages people complain about and programming languages nobody uses'. However the Python libraries absolutely rock and the ease with which you can get really performant number crunching code out of what is nominally an interpreted language is amazing. Statistics, machine learning, engineering, the notebooks etc, I would not pick anything else for work like that, it's a near infinite box full of powertools. But it would be a mistake to consider Python anything but luxury glue no matter how much you've used it for production code, it isn't and never will be a bullet proof language, there are just too many ways in which the runtime can surprise you and the long term maintainability of any Python codebase is always going to be questionable, in part because you will most likely have dependencies on stuff that will silently disappear or change out from under you while you're not watching. I've been writing Python code pretty much since it was first released and there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change. This as opposed to just about every other language that I've used, which I find very frustrating because Python could be just about perfect. And I'm still sore about significant whitespace ;)
  - onatrain 4y ago
    > there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact). (Seems like a lot of people are using system Python, which isn't really recommended.)
    - cinquemb 4y ago
      Yeah, I have no problem running stuff from a decade ago because of virtual env and pip freeze (even across diff oses).
      - jacquesm 4y ago
        I have no problem running stuff from a decade ago either on the same box and installation that it was on a decade ago. But virtual environments and pip freeze are closer to mothballing an old box than displaying long term code compatibility and functionality. Their main reason to exist is as a workaround precisely because there are such issues. The whole idea that you need a multitude of environments to support applications written in the same interpreted language is where it breaks, that should not have been necessary if backwards compatibility had not been an issue.
    - fsh 4y ago
      I started a project in 2016 and used pipenv to freeze all the dependencies. A few weeks ago, I could not get it working on a new machine. Apparently the new system python broke some of the libraries. I had also pinned the python version in pipenv, but it seems like pipenv can only install python versions that are not too old. I really like the language, but all the tooling is seriously broken.
      - pksebben 4y ago
        pyenv will make your life easier in this regard. that is all.
- groestl 4y ago
  The string/bytes encoding lead to some weird runtime problems in a codebase I maintain (the quality of which is probably not that great to begin with). Also changes in non-statically compiled languages will always be a bit tricky. In general, a comprehensive unit test suite is required to step in for the compiler, otherwise there's no confident refactoring. But python is sooooo ubiquitous it's crazy, and most code does not have unit tests to make up for missing compile time checks. The codebase I mentioned earlier certainly doesn't.
  - erik_seaberg 4y ago
    I’m pretty cautious about changing my own code, but even I am not paranoid enough to write tests to verify that freakin’ strings still have the behavior I rely on. At least not until the day they suddenly didn’t.
    - groestl 4y ago
      Yes, and that's one reason why a static compiled type system helps you maintain code, dependencies and language I'd say.
      - t43562 4y ago
        I tried adding type hinting to a program that I had to maintain once - because it had no unit tests and I was looking for the quickest way to make it less fragile. One tended to make a small change and then find that it broke something somewhere but finding that out was a long process. FWIW I found it nearly useless - whereas biting the bullet and refactoring it so that it could be unit tested - even just a few tests - made a world of difference.
    - nibbleshifter 4y ago
      > At least not until the day they suddenly didn’t. That's been happening more and more recently to me. Python 2 really was lax about letting you mix types and get shit done fast, but Python 3 is a different beast entirely. Really opinionated.
  - 4y ago
- TylerE 4y ago
  It wasn’t so much the difficulty, but how little all that effort got you. It took them until about 3.7 to even reach performance parity. It was all stick no carrot.
- gurustave 4y ago
  Probably not. Java is going through the same exact thing with Java 8 right now. The issue is that humans don't plan ahead for when the software they use inevitably goes EOL, be it programming languages, libraries, or operating systems, and so only really do so when forced (sometimes only after a security incident). In the case of Python 2 and Java 8, the problem was/has been exacerbated by the organization supporting the software continuing to push the support window out further to "give time to upgrade" because in response everyone either said "I have time, I'll get to it later" or "I'll wait for the next newest version". For Java 8 especially, the later reason is particularly amusing, as Oracle's extended support is now slated to go to 2030 (16yrs after release, for comparison Py2.7 got 10yrs), but Java 21, the next Java LTS that should release next year, will be on Oracle's standard 8 year extended support cycle, and thus extended support only goes til 2031. So why would anyone decide, much less how would one justify to a corporate overlord, to spend all the time and resources to refactor their code, upgrade libraries (assuming the libraries themselves upgrade), update build systems, perform extensive regression testing, and everything else, just for a version that would be EOL one year after what they just upgraded from?
  - estebank 4y ago
    > So why would anyone decide, much less how would one justify to a corporate overlord, to spend all the time and resources to refactor their code, upgrade libraries (assuming the libraries themselves upgrade), update build systems, perform extensive regression testing, and everything else, just for a version that would be EOL one year after what they just upgraded from? The longer you delay upgrades, the bigger the delta, the more work it will be to update. Instead of doing two medium sized updates, one today and another one in 2030, you'll be doing a huge one in 2030. That might be a trade off you might be willing to make today, but you might regret it in 2029 when you're halfway through a multiyear migration project where all feature work is on hold.
    - erik_seaberg 4y ago
      Most Java versions are good about backcompat, almost all the pain comes with Java 9 actually enforcing boundaries and breaking things that had merely been discouraged before (in the name of JDK modularization, which we otherwise aren’t interested in).
- rich_sasha 4y ago
  I think that's missing the point a little. The actual migration should you choose to do it was almost trivial. The official conversion script did most if not all the work. The changes were all cosmetic, like "print 42" changing to "print(42)". I'd say the uproar was about the minorness itself. The syntax had these tiny but otherwise incompatible changes, and for many people, for no good reason. Fo example it was deemed that, as in the example above, print shall not be a statement anymore, but a function instead. Why? Unclear. Meanwhile, Python 3 offered few concrete improvements to many users So I think the 2->3 moan, of which I was a party, was about that: minor, unnecessary changes that introduced little to no benefit, and yet backwards-incompatible.
  - yjftsjthsd-h 4y ago
    > The actual migration should you choose to do it was almost trivial. The official conversion script did most if not all the work. The changes were all cosmetic, like "print 42" changing to "print(42)". If that were it, it'd have been over a lot sooner. For some packages, bytes vs Unicode strings was bad. For many more, layers of dependencies were an impediment. The trivial stuff wasn't the problem.
    - rich_sasha 4y ago
      For some, sure. But for example a big stumbling block was the scientific programming community, from which I also stem. There were no major syntactical reasons there and yet people were up in arms, for the reasons I describe above. Most people I know migrated only when python2 literally wouldnt work for them anymore, like they needed a feature of a library only released for python3.
- noobermin 4y ago
  And yet it says a lot that people stayed, I'm not sure it says whether the python 3 move was necessary more than it says something about developers in general.
- ThreePinkApples 4y ago
  If this was a frequent event then yes that would be an issue. But Python 3 released in 2008, more than 14 years ago now, and since then there have been no sign of such a new big change. While the core developers briefly talked about making Python 3.10 into 4.0 that was scrapped, and currently the plan is just to continue with Python 3.x "forever".
- mike_hock 4y ago
  Any time someone argues for a breaking change that will have oh so many benefits if we just get the whole ecosystem upgraded this one time, it should come with an explanation of how the new version will manage to make the same substantial changes without breaking any code again, or it shouldn't be taken seriously.
Galanwe 4y ago
from __future__ import print_function print("goodbye, sweet prince")
hoseja 4y ago
I can't even imagine what terrible hacks you had to spawn to be able to claim this.
- nibbleshifter 4y ago
  A lot of code I wrote over the years handles raw bytes, treating them as strings (sometimes), shuffling them over sockets, doing stupid things with said sockets, etc. Lots of abuse of how weakly/poorly/forgivingly typed Py2 is. Doing the same processes in Py3 is actually headache inducing because of the much stronger typing system.

bmitc 4y ago

Doesn't this say something about the language if it's been so difficult for people to migrate from 2 to 3? Yes, it was a major version change, but it doesn't bode well for arguments that Python is a good language to do long-term, maintainable, and large-scale development. Sure, now things are "settled" with 3, but Python continues to get more features. It just doesn't look good for the language if even doing a language version migration was a literal brick wall for so much of the community.

jacquesm 4y ago
Let me be blunt here: Python sucks, but that's at the level of 'programming languages people complain about and programming languages nobody uses'. However the Python libraries absolutely rock and the ease with which you can get really performant number crunching code out of what is nominally an interpreted language is amazing. Statistics, machine learning, engineering, the notebooks etc, I would not pick anything else for work like that, it's a near infinite box full of powertools. But it would be a mistake to consider Python anything but luxury glue no matter how much you've used it for production code, it isn't and never will be a bullet proof language, there are just too many ways in which the runtime can surprise you and the long term maintainability of any Python codebase is always going to be questionable, in part because you will most likely have dependencies on stuff that will silently disappear or change out from under you while you're not watching. I've been writing Python code pretty much since it was first released and there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change. This as opposed to just about every other language that I've used, which I find very frustrating because Python could be just about perfect. And I'm still sore about significant whitespace ;)
- onatrain 4y ago
  > there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact). (Seems like a lot of people are using system Python, which isn't really recommended.)
  - cinquemb 4y ago
    Yeah, I have no problem running stuff from a decade ago because of virtual env and pip freeze (even across diff oses).
    - jacquesm 4y ago
      I have no problem running stuff from a decade ago either on the same box and installation that it was on a decade ago. But virtual environments and pip freeze are closer to mothballing an old box than displaying long term code compatibility and functionality. Their main reason to exist is as a workaround precisely because there are such issues. The whole idea that you need a multitude of environments to support applications written in the same interpreted language is where it breaks, that should not have been necessary if backwards compatibility had not been an issue.
  - fsh 4y ago
    I started a project in 2016 and used pipenv to freeze all the dependencies. A few weeks ago, I could not get it working on a new machine. Apparently the new system python broke some of the libraries. I had also pinned the python version in pipenv, but it seems like pipenv can only install python versions that are not too old. I really like the language, but all the tooling is seriously broken.
    - pksebben 4y ago
      pyenv will make your life easier in this regard. that is all.
groestl 4y ago
The string/bytes encoding lead to some weird runtime problems in a codebase I maintain (the quality of which is probably not that great to begin with). Also changes in non-statically compiled languages will always be a bit tricky. In general, a comprehensive unit test suite is required to step in for the compiler, otherwise there's no confident refactoring. But python is sooooo ubiquitous it's crazy, and most code does not have unit tests to make up for missing compile time checks. The codebase I mentioned earlier certainly doesn't.
- erik_seaberg 4y ago
  I’m pretty cautious about changing my own code, but even I am not paranoid enough to write tests to verify that freakin’ strings still have the behavior I rely on. At least not until the day they suddenly didn’t.
  - groestl 4y ago
    Yes, and that's one reason why a static compiled type system helps you maintain code, dependencies and language I'd say.
    - t43562 4y ago
      I tried adding type hinting to a program that I had to maintain once - because it had no unit tests and I was looking for the quickest way to make it less fragile. One tended to make a small change and then find that it broke something somewhere but finding that out was a long process. FWIW I found it nearly useless - whereas biting the bullet and refactoring it so that it could be unit tested - even just a few tests - made a world of difference.
  - nibbleshifter 4y ago
    > At least not until the day they suddenly didn’t. That's been happening more and more recently to me. Python 2 really was lax about letting you mix types and get shit done fast, but Python 3 is a different beast entirely. Really opinionated.
- 4y ago
TylerE 4y ago
It wasn’t so much the difficulty, but how little all that effort got you. It took them until about 3.7 to even reach performance parity. It was all stick no carrot.
gurustave 4y ago
Probably not. Java is going through the same exact thing with Java 8 right now. The issue is that humans don't plan ahead for when the software they use inevitably goes EOL, be it programming languages, libraries, or operating systems, and so only really do so when forced (sometimes only after a security incident). In the case of Python 2 and Java 8, the problem was/has been exacerbated by the organization supporting the software continuing to push the support window out further to "give time to upgrade" because in response everyone either said "I have time, I'll get to it later" or "I'll wait for the next newest version". For Java 8 especially, the later reason is particularly amusing, as Oracle's extended support is now slated to go to 2030 (16yrs after release, for comparison Py2.7 got 10yrs), but Java 21, the next Java LTS that should release next year, will be on Oracle's standard 8 year extended support cycle, and thus extended support only goes til 2031. So why would anyone decide, much less how would one justify to a corporate overlord, to spend all the time and resources to refactor their code, upgrade libraries (assuming the libraries themselves upgrade), update build systems, perform extensive regression testing, and everything else, just for a version that would be EOL one year after what they just upgraded from?
- estebank 4y ago
  > So why would anyone decide, much less how would one justify to a corporate overlord, to spend all the time and resources to refactor their code, upgrade libraries (assuming the libraries themselves upgrade), update build systems, perform extensive regression testing, and everything else, just for a version that would be EOL one year after what they just upgraded from? The longer you delay upgrades, the bigger the delta, the more work it will be to update. Instead of doing two medium sized updates, one today and another one in 2030, you'll be doing a huge one in 2030. That might be a trade off you might be willing to make today, but you might regret it in 2029 when you're halfway through a multiyear migration project where all feature work is on hold.
  - erik_seaberg 4y ago
    Most Java versions are good about backcompat, almost all the pain comes with Java 9 actually enforcing boundaries and breaking things that had merely been discouraged before (in the name of JDK modularization, which we otherwise aren’t interested in).
rich_sasha 4y ago
I think that's missing the point a little. The actual migration should you choose to do it was almost trivial. The official conversion script did most if not all the work. The changes were all cosmetic, like "print 42" changing to "print(42)". I'd say the uproar was about the minorness itself. The syntax had these tiny but otherwise incompatible changes, and for many people, for no good reason. Fo example it was deemed that, as in the example above, print shall not be a statement anymore, but a function instead. Why? Unclear. Meanwhile, Python 3 offered few concrete improvements to many users So I think the 2->3 moan, of which I was a party, was about that: minor, unnecessary changes that introduced little to no benefit, and yet backwards-incompatible.
- yjftsjthsd-h 4y ago
  > The actual migration should you choose to do it was almost trivial. The official conversion script did most if not all the work. The changes were all cosmetic, like "print 42" changing to "print(42)". If that were it, it'd have been over a lot sooner. For some packages, bytes vs Unicode strings was bad. For many more, layers of dependencies were an impediment. The trivial stuff wasn't the problem.
  - rich_sasha 4y ago
    For some, sure. But for example a big stumbling block was the scientific programming community, from which I also stem. There were no major syntactical reasons there and yet people were up in arms, for the reasons I describe above. Most people I know migrated only when python2 literally wouldnt work for them anymore, like they needed a feature of a library only released for python3.
noobermin 4y ago
And yet it says a lot that people stayed, I'm not sure it says whether the python 3 move was necessary more than it says something about developers in general.
ThreePinkApples 4y ago
If this was a frequent event then yes that would be an issue. But Python 3 released in 2008, more than 14 years ago now, and since then there have been no sign of such a new big change. While the core developers briefly talked about making Python 3.10 into 4.0 that was scrapped, and currently the plan is just to continue with Python 3.x "forever".
mike_hock 4y ago
Any time someone argues for a breaking change that will have oh so many benefits if we just get the whole ecosystem upgraded this one time, it should come with an explanation of how the new version will manage to make the same substantial changes without breaking any code again, or it shouldn't be taken seriously.

Galanwe 4y ago

from __future__ import print_function print("goodbye, sweet prince")

hoseja 4y ago

I can't even imagine what terrible hacks you had to spawn to be able to claim this.

nibbleshifter 4y ago
A lot of code I wrote over the years handles raw bytes, treating them as strings (sometimes), shuffling them over sockets, doing stupid things with said sockets, etc. Lots of abuse of how weakly/poorly/forgivingly typed Py2 is. Doing the same processes in Py3 is actually headache inducing because of the much stronger typing system.