10 ms·

> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm

by Narann 9y ago

> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7. And we are a tiny focused industry. So I'm sure there is many other industries like us which are 2.7 that you will never heard of. That's why "most popular" mean nothing once you take how Python is use as a whole. We don't use any of this web/Internet/network "popular" packages. I'm not saying Python shouldn't move on. I'm just trying to argue against this "most popular packages" while millions of us, even if you don't know it, us none of those.

notspanishflu 9y ago
I know some "tiny focused industry" that's still using DOS.
- xab9 9y ago
  I see a DOS application running on XP all the time I go and visit the local doctor (social healthcare, regional center).
  - pjmlp 9y ago
    Given the use case, I bet it was most likely written in Clipper.
    - xab9 9y ago
      Probably, friend of mine seen a dbase one lately...
audiolion 9y ago
If you arent using the packages that most people use, and decided to roll your own, then it is on you to upgrade. Not seeing the issue here of course your custom niche libraries havent been upgraded if you havent been diligent. The py2 end of life is supposed to give your manager hard reasons to switch. But if you never use pypi packages and dont interact with the web, you dont need to upgrade, as you don't need to install packages that might be 3 only and you dont have potential for security vulnerabilities.
sametmax 9y ago
Well, the CGI industry had money, competent people, and 10 years to upgrade. An entire decade. And a LOT of tooling and documentation to help. I made a lot of code conversion from 2 to 3. Most of them took me a couple hours to a few days. I'm currently working on a 2.7 project that will never migrate because they literally patched the cpython runtime, but you can't freeze a whole community because some will take bad technical decisions or accumulate tons of technical debt. Now, Python 2.7 will not stops working after 2020. It's just that we, as a community, will stop to pay the price for the ones that didn't move. If you want to stay there, you'll pay a commercial actor for it. In 2020 centos 6 will stop received updates. Will you go complain that the new RPM are not compatible ? No, either you update, or you pay commercial support. Ruby and node did it in a few months and told the community to move or die. Nobody complained. Perl took so long the language has been forgotten. PHP literally canceled the version 6, and made it taboo. We gave years, and means, then extended the deadline, and heard nothing but complaining since. I won't pretend the migration was masterfully executed. The whole 2/3 debacle was painful. But, it's been since 2008, come on.
- crististm 9y ago
  2.7 is a different language than 3.x. You could argue that 2.y is also a different language than 2.x but this is besides the point: as long as there is a compiler for that language and it works (for your definition of works) you don't need to translate your programs in another language just because you have money.
  - rocqua 9y ago
    > you don't need to translate your programs in another language just because you have money. True, but if you know the support behind your current language is going to go away, it might be smart to migrate.
    - crististm 9y ago
      Yes but this is a different argument. He could have said "if you are smart" instead of "if you have the money". See?
pjmlp 9y ago
Well, I also imagine that the native code is mostly C89 or C++98.
badsectoracula 9y ago
Projects that need to continue using 2.7 can use a fork that promises to preserve backwards compatibility like Tauthon: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
bjt2n3904 9y ago
Hello from the embedded world! The web world indeed can rapidly change their entire stack from LAMP to MEAN to Dockerized Q-Basic CGI scripts and load balance their Twitter clone. There's challenges for sure, but pushing updates is simple and quick, and you can always throw more cloud if you run into walls. If your complete platform rewrite fails, just roll the load balancer back over and try again tomorrow. It's a lot more difficult when your Python application is communicating with a temperamental motor controller over an ancient RS-232 link with AT commands. There are only ten of these devices in the world, and three in deployment. They perform critical functions, and they need to run 24/7 without failure or human interaction. (Did I mention these devices are remote, and it takes an afternoon to go out and investigate a failure?) Every single failure results in a few lines of change in the code base. Those lines cost quite a bit -- both time, money, and loss. It's quite stable now, but that stability came at a price. But haha, what am I talking about? Geez, I've had ten years to move off this "dead" platform. Let's run it through 2to3, or perhaps try a port to nodejs and deploy it tomorrow.
- abritinthebay 9y ago
  I’m not sure what you’re complaining about here. Those applications will still work.
  - bjt2n3904 9y ago
    The attitude of most python3 devs, which can be surmised as: "I moved my Twitter clone from python2 to python3, and it was easy. What's the big problem? You've had ten years to get this done! Hurry up, you're hurting my productivity."
    - abritinthebay 9y ago
      Well if you’re not happy about the EoL part then that’s a fair response. If you don’t care (because your apps will still work and they don’t need or can’t be updated) then it shouldn’t really come up...?
    - freyir 9y ago
dajonker 9y ago
I don't understand your argument. If you don't use any of those packages, then indeed it does not matter. As with all decisions, whether this argument applies to you depends on your situation, but in my experience incompatible packages were often the most important reason not to choose 3.x.
dagmx 9y ago
The CG industry (atleast for vfx) is moving to python 3 starting next year. Python 3 is part of the cy2019 reference platform.
mixmastamyk 9y ago
If you're not doing much/any text encoding, guessing graphics/VFX is not, then upgrading is pretty painless these days.
zzzeek 9y ago
by "the CGI industry" you most likely mean Disney. Disney can afford the investment to make the upgrade.
dnautics 9y ago
it's really not a big deal. If you absolutely need legacy python support, you will very likely be able to solve it using a virtualized or containerized environment.

by Narann 9y ago

notspanishflu 9y ago

I know some "tiny focused industry" that's still using DOS.

xab9 9y ago
I see a DOS application running on XP all the time I go and visit the local doctor (social healthcare, regional center).
- pjmlp 9y ago
  Given the use case, I bet it was most likely written in Clipper.
  - xab9 9y ago
    Probably, friend of mine seen a dbase one lately...

audiolion 9y ago

If you arent using the packages that most people use, and decided to roll your own, then it is on you to upgrade. Not seeing the issue here of course your custom niche libraries havent been upgraded if you havent been diligent. The py2 end of life is supposed to give your manager hard reasons to switch. But if you never use pypi packages and dont interact with the web, you dont need to upgrade, as you don't need to install packages that might be 3 only and you dont have potential for security vulnerabilities.

sametmax 9y ago

Well, the CGI industry had money, competent people, and 10 years to upgrade. An entire decade. And a LOT of tooling and documentation to help. I made a lot of code conversion from 2 to 3. Most of them took me a couple hours to a few days. I'm currently working on a 2.7 project that will never migrate because they literally patched the cpython runtime, but you can't freeze a whole community because some will take bad technical decisions or accumulate tons of technical debt. Now, Python 2.7 will not stops working after 2020. It's just that we, as a community, will stop to pay the price for the ones that didn't move. If you want to stay there, you'll pay a commercial actor for it. In 2020 centos 6 will stop received updates. Will you go complain that the new RPM are not compatible ? No, either you update, or you pay commercial support. Ruby and node did it in a few months and told the community to move or die. Nobody complained. Perl took so long the language has been forgotten. PHP literally canceled the version 6, and made it taboo. We gave years, and means, then extended the deadline, and heard nothing but complaining since. I won't pretend the migration was masterfully executed. The whole 2/3 debacle was painful. But, it's been since 2008, come on.

crististm 9y ago
2.7 is a different language than 3.x. You could argue that 2.y is also a different language than 2.x but this is besides the point: as long as there is a compiler for that language and it works (for your definition of works) you don't need to translate your programs in another language just because you have money.
- rocqua 9y ago
  > you don't need to translate your programs in another language just because you have money. True, but if you know the support behind your current language is going to go away, it might be smart to migrate.
  - crististm 9y ago
    Yes but this is a different argument. He could have said "if you are smart" instead of "if you have the money". See?

pjmlp 9y ago

Well, I also imagine that the native code is mostly C89 or C++98.

badsectoracula 9y ago

Projects that need to continue using 2.7 can use a fork that promises to preserve backwards compatibility like Tauthon: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon

bjt2n3904 9y ago

Hello from the embedded world! The web world indeed can rapidly change their entire stack from LAMP to MEAN to Dockerized Q-Basic CGI scripts and load balance their Twitter clone. There's challenges for sure, but pushing updates is simple and quick, and you can always throw more cloud if you run into walls. If your complete platform rewrite fails, just roll the load balancer back over and try again tomorrow. It's a lot more difficult when your Python application is communicating with a temperamental motor controller over an ancient RS-232 link with AT commands. There are only ten of these devices in the world, and three in deployment. They perform critical functions, and they need to run 24/7 without failure or human interaction. (Did I mention these devices are remote, and it takes an afternoon to go out and investigate a failure?) Every single failure results in a few lines of change in the code base. Those lines cost quite a bit -- both time, money, and loss. It's quite stable now, but that stability came at a price. But haha, what am I talking about? Geez, I've had ten years to move off this "dead" platform. Let's run it through 2to3, or perhaps try a port to nodejs and deploy it tomorrow.

abritinthebay 9y ago
I’m not sure what you’re complaining about here. Those applications will still work.
- bjt2n3904 9y ago
  The attitude of most python3 devs, which can be surmised as: "I moved my Twitter clone from python2 to python3, and it was easy. What's the big problem? You've had ten years to get this done! Hurry up, you're hurting my productivity."
  - abritinthebay 9y ago
    Well if you’re not happy about the EoL part then that’s a fair response. If you don’t care (because your apps will still work and they don’t need or can’t be updated) then it shouldn’t really come up...?
  - freyir 9y ago

dajonker 9y ago

I don't understand your argument. If you don't use any of those packages, then indeed it does not matter. As with all decisions, whether this argument applies to you depends on your situation, but in my experience incompatible packages were often the most important reason not to choose 3.x.

dagmx 9y ago

The CG industry (atleast for vfx) is moving to python 3 starting next year. Python 3 is part of the cy2019 reference platform.

mixmastamyk 9y ago

If you're not doing much/any text encoding, guessing graphics/VFX is not, then upgrading is pretty painless these days.

zzzeek 9y ago

by "the CGI industry" you most likely mean Disney. Disney can afford the investment to make the upgrade.

dnautics 9y ago

it's really not a big deal. If you absolutely need legacy python support, you will very likely be able to solve it using a virtualized or containerized environment.