Several shared-hosting companies don't support Python 3 yet. HostGator's default Python is still 2.6.
[deleted]
Python 2 will be replaced with Python 3 in the next RHEL major release
181–190 of 341 posts
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#182About goddamn time. Now let's take care of PHP <= 7 and Node <= 8 and us sysadmins can stop living a foot in a decade ago and a foot in today.
> Node
Great! Mostly no problem. The backwards-incompatible changes are few and seem to rarely be used in the projects I've seen.
> PHP
Totally different story. PHP does upgrade slowly, but many of the backwards-incompatible changes are almost impossible to detect without 100% code coverage. A lot of legacy PHP That said, I think bespoke PHP is less common than people think. The WordPress/Drupal/whatever installations are major drivers of the usage numbers for PHP.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#183This 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
> "Most popular" packages, which ones? Most moved a long time ago to Python 3
The person you replied to said
> most popular packages are now compatible with Python 3
so it looks like you two are in agreement there.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#184I wonder how things will fare for Mercurial, or GYP (used by Node.js).
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#185Earlier quoted context omitted.
We've switched from 2.7 to 3.4 (and upwards to 3.5, 3.6) in about a month or so. It delayed some deployments but nothing serious. If you do it step-by-step it's not that hard. The worst part was str/binary conversions but afterwards everything was a lot easier and better to maintain. If your company is big enough you should maintain and keep it up-to-date, not "it just works"(TM) and hope for the best after 10 years.…
It's not that hard unless you had some very advanced code utilizing Python 2 internals that were significantly changed in Python 3. However, conversion takes a lot of time and if something works, why should you be forced to change it?
Because non-IT users (your customers) are sick and tired of apps from 2000 that run clunky and ugly because someone is "forcing you change it" (aka doing your job) and you don't feel like it. Yes,
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#186Earlier quoted context omitted.
No that's just how IT works. 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 a…
> Your games don't work in windows XP anymore. In fact I can play EarthSiege 2, a game from the 3.11/Win95 era, just fine on Win7 x64 with the only things not working being joystick input (I guess it does some shenanigans with the MIDI/joystick port in addition to using the windows joystick API) and the pause screen which shows your vehicle spinning around spins too fast (probably because its speed is tethered to CPU…
Whenever this comes up I feel it is worth pointing out that Linux's "Things break" approach is a problem exclusive to the userland tooling built up around the kernel. Linus takes a very hardline stance against breaking kernel ABI compatibility (except for drivers), but pretty much every piece of software outside of that, including GLIBC, thinks it's totally ok to break things all the time.
It's really very sad that the Linux community never adopted Linus's view.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#187This 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.
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
Php3 and php4? Php4 and 5? Then I've lost contact with pure php
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#188Earlier quoted context omitted.
It's not that hard unless you had some very advanced code utilizing Python 2 internals that were significantly changed in Python 3. However, conversion takes a lot of time and if something works, why should you be forced to change it?
Because non-IT users (your customers) are sick and tired of apps from 2000 that run clunky and ugly because someone is "forcing you change it" (aka doing your job) and you don't feel like it. Yes,
[deleted]
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#189Earlier quoted context omitted.
True, but is there a situation where upgrading will hurt instead of benefit? Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme. For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, t…
Yes, upgrading is an engineering expenditure like any other. If you devote manpower to maintaining your codebase you're not devoting it to user-facing features. As such, upgrading your codebase can hurt your ability to deliver some priority feature on-time. But that kind of zero-sum thinking is myopic. My whole point is that if you only ever prioritize feature work, eventually you lose the ability to deliver features…
That's right, but...
It seems to me that all counter-arguments I get ignore the context that I set which is to not do things "simply because you have the money".
What I get is "hey, you have the money and it's obviously the right thing to do so do it".
"Having the money" is orthogonal to "it's the right thing to do" but this thread is too old to recover.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#190Earlier quoted context omitted.
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
I guess you haven’t looked at Swift. All 4 major versions are very incompatible.
It's still a young language and doesn't have as much legacy codebases as python.