4 ms·

At this point, I swear, the main source of difficulty in Python 2->3 is all the foot-dragging in migrating to Python 3. I wouldn't be at all surprised to discov

At this point, I swear, the main source of difficulty in Python 2->3 is all the foot-dragging in migrating to Python 3. I wouldn't be at all surprised to discover that vastly more Python 2 code was written in the past twelve years than in the preceding eight.

MattGaiser 6y ago
A friend of mine uses Python in his lab. Tons of them were writing Python 2 code when they were learning it two years ago (Feb 2019). So they started from scratch with it two years ago.
josefx 6y ago
> the main source of difficulty in Python 2->3 is all the foot-dragging in migrating to Python 3. My main difficulty was having targets that ran python 2 and wouldn't get an official python 3 package unless a miracle happened. Meanwhile most systems supporting python 3 also had a python 2 package. Ended up porting a few scripts to a statically linked c++ binary, those should keep on working until we get 128 bit systems that drop support for 64 bit binaries.
- busterarm 6y ago
  You learned an important lesson about distributing software and business risk. In my experiences trying to deploy software at scale (10^4~5), statically linked binaries are the only acceptable form of software.
  - yjftsjthsd-h 6y ago
    If you don't have a pipeline to update those static binaries, you're just giving yourself a different form of headache 5 years from now when you need to apply bug fix.
    - lanstin 6y ago
      With static linking you mostly have all the pieces updatable independently. Can move to new distro and keep the binaries. Can update some binaries with a bug fix to some parser library without releasing other binaries. Etc. except for glibc and stuff like 64-bit inode values.
    - busterarm 6y ago
      That's not a deployment problem though. And if everything you did to build those binaries failed, you can still run those binaries. You aren't out of business. We're talking about this versus the alternative of potentially not being able to deploy anything. Then you're dead. In both cases you needed a build pipeline anyway...unless you're operating in a world where "it works on my machine" is a good enough answer.
      - jart 6y ago
        If you like static binaries then you'll love this project: https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html Here's an example of a 64kb statically linked binary that runs on all operating systems https://justine.lol/memzoom/index.html https://justine.lol/memzoom/index.html
  - formerly_proven 6y ago
    That’s very true but making “static distributions” of Python apps is a fairly hacky/annoying problem with lots of room for subtle breakage. In practice one static pkg per major district version seems advisable. Curiously Linux, despite having an extremely stable user space interface, suffers from a high degree of user space incompatibility. This starts with glibc and its components and ends with graphical toolkits. Go seems to be very successful because it ditches all of that crud and goes for the stable interface instead.
    - busterarm 6y ago
      I'm pretty sure that I was quite blatantly suggesting that Python fails to meet suitability. That doesn't mean we don't use it...because people like it. But it adds complexity and "business risk", whether you like it or not. In some spaces (ML) you're going to have to ship some Python, but what I was saying was that I would rather not. My role the past few years has been some mix of deployment engineering & systems engineering and the conclusion that I quickly came to was that deploying scripting languages like Python/Ruby/etc is the realm of assholes. ...which was a funny lesson because mainly through my career I've worked in smaller scale shops using almost exclusively scripting languages.
EamonnMR 6y ago
Lots of people probably wrote against whatever python their system shipped with which was inevitably a python 2.

MattGaiser 6y ago

A friend of mine uses Python in his lab. Tons of them were writing Python 2 code when they were learning it two years ago (Feb 2019). So they started from scratch with it two years ago.

josefx 6y ago

> the main source of difficulty in Python 2->3 is all the foot-dragging in migrating to Python 3. My main difficulty was having targets that ran python 2 and wouldn't get an official python 3 package unless a miracle happened. Meanwhile most systems supporting python 3 also had a python 2 package. Ended up porting a few scripts to a statically linked c++ binary, those should keep on working until we get 128 bit systems that drop support for 64 bit binaries.

busterarm 6y ago
You learned an important lesson about distributing software and business risk. In my experiences trying to deploy software at scale (10^4~5), statically linked binaries are the only acceptable form of software.
- yjftsjthsd-h 6y ago
  If you don't have a pipeline to update those static binaries, you're just giving yourself a different form of headache 5 years from now when you need to apply bug fix.
  - lanstin 6y ago
    With static linking you mostly have all the pieces updatable independently. Can move to new distro and keep the binaries. Can update some binaries with a bug fix to some parser library without releasing other binaries. Etc. except for glibc and stuff like 64-bit inode values.
  - busterarm 6y ago
    That's not a deployment problem though. And if everything you did to build those binaries failed, you can still run those binaries. You aren't out of business. We're talking about this versus the alternative of potentially not being able to deploy anything. Then you're dead. In both cases you needed a build pipeline anyway...unless you're operating in a world where "it works on my machine" is a good enough answer.
    - jart 6y ago
      If you like static binaries then you'll love this project: https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html Here's an example of a 64kb statically linked binary that runs on all operating systems https://justine.lol/memzoom/index.html https://justine.lol/memzoom/index.html
- formerly_proven 6y ago
  That’s very true but making “static distributions” of Python apps is a fairly hacky/annoying problem with lots of room for subtle breakage. In practice one static pkg per major district version seems advisable. Curiously Linux, despite having an extremely stable user space interface, suffers from a high degree of user space incompatibility. This starts with glibc and its components and ends with graphical toolkits. Go seems to be very successful because it ditches all of that crud and goes for the stable interface instead.
  - busterarm 6y ago
    I'm pretty sure that I was quite blatantly suggesting that Python fails to meet suitability. That doesn't mean we don't use it...because people like it. But it adds complexity and "business risk", whether you like it or not. In some spaces (ML) you're going to have to ship some Python, but what I was saying was that I would rather not. My role the past few years has been some mix of deployment engineering & systems engineering and the conclusion that I quickly came to was that deploying scripting languages like Python/Ruby/etc is the realm of assholes. ...which was a funny lesson because mainly through my career I've worked in smaller scale shops using almost exclusively scripting languages.

EamonnMR 6y ago

Lots of people probably wrote against whatever python their system shipped with which was inevitably a python 2.