This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years 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 in…
Python 2 will be replaced with Python 3 in the next RHEL major release
121–130 of 341 posts
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#122Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#123Earlier quoted context omitted.
Python could be written that way (2/3-compatible) as well and plenty of programs and modules were.
Uhhhh... sort of? I mean, I could go through all of the needless "why the hell did they make this partner incompatible also" stuff like, like removing u'' support (thai was added later), or all of the ludicrous breakage in the underlying APIs (like filesystem calls that made assumptions about character encoding that make no sense for the underlying Unix model and literally caused files to just disappear from iteratio…
- if you tried to support Python - if you tried to support Python But nobody used 3.0, 1 or 2. And supporting 2.6 is like supporting ruby 1.7 and 1.8 and 1.9. Which nobody did.
And it's easy to rewrite libs when really the language started to be used in 2004.
Or maybe not, given that "gem install" still regularly crashes on anything other than the top 20 packages, so it's still not a solved issue.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#124Earlier quoted context omitted.
You don't need to upgrade your servers to the lastest linux kernel either. But in 10 years, you won't get any security update for it, unless you pay a lot of money for it. It will be the same for Python. You want the excellent and money making free work of volunteers ? Do your part. You don't want too ? It's ok. In 2020, plenty of companies will sale you services for the real market price of your technical debt.
Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.
I don't think that centos 6 is bug free yet it EOL in 2010 too.
Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox.
My client won't upgrade. They pay support, expensive support, to keep their old version.
In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't migrate.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#125Earlier quoted context omitted.
As VB6 is compiled, you don't need your users to have a particular interpreter version installed.
I do remember the good old days of having to make sure you had MSVBVM50.DLL or MSVBVM60.DLL in the right place...
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#126This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.
Got a source for the performance regressions? Some things are faster in Python 3 than 2 "Most popular" packages, which ones? Most moved a long time ago to Python 3
Basically once 3.7 is out (which is soon), CPython3 will finally be broadly faster than CPython2.7.
Interpreter startup time is still annoying though. I really wonder what the right strategy for addressing that is. Like honestly 2.7 is faster than 3.x, but 2.7 CLI tools still feel silly to use.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#127Earlier quoted context omitted.
Quite the opposite. Python had deep problems that could simply not be fixed without BC breaks. The decision was made, and in hindsight it was the correct decision by Guido and other core devs. Look at PHP, and look what a total cluster of madness the language has become.
I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improv…
Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got cross platform support and seems to have stalled out.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#128Earlier quoted context omitted.
> 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 in…
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…
That's very well put. But I guess this can happen only with big, important, projects where you can afford to loose/upset some users...
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#129Earlier quoted context omitted.
You don't need to upgrade your servers to the lastest linux kernel either. But in 10 years, you won't get any security update for it, unless you pay a lot of money for it. It will be the same for Python. You want the excellent and money making free work of volunteers ? Do your part. You don't want too ? It's ok. In 2020, plenty of companies will sale you services for the real market price of your technical debt.
Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.
Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will.
(small and non-notable exceptions for the literal handful of types of orgs where this is not the case)
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#130Earlier quoted context omitted.
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…
>> 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. That's very well put. But I guess this can happen only with big, important, projects where you can afford to loose/upset some users...
Your games don't work in windows XP anymore. Actually, your USB3 mouse doesn't work on windows 7 out of the box.
Centos have LTS, but still EOL.
Ubuntu init system was changed to upstart. Then to systemd. Also gnome, then unity, then with new menu/notif/systray semantics, then back to gnome (but shell), and soon wayland. It breaks a lot of things.
Firefox new addons don't work with some addons from last year.
NodeJS had 3 incompatible forks in it's short life.
Twitter and Facebook API breaks every sunday.
JS frameworks are just madness.
Python break compat, ONCE.
Once since 1990.
Also gave 10 years to migrate.
In our industry, that's not bad at all.
And the community hold. We worked. We wrote tools, doc, blog posts. We were there all the way. We have incredible libs like python-future to help.
And if any of that is not enough, well, Anaconda Continuum will be happy to do business with you.
It's how it is.