About 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.
HERE FREAKING HERE
Would you please not post unsubstantive comments to Hacker News?
Python 2 will be replaced with Python 3 in the next RHEL major release
301–310 of 341 posts
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#302I think this has been the ugliest, most badly managed update for a major language since Perl6. And this is not completely over, yet. Over the next 5 years I still expect to see people complaining about this Python3 thing. I hope the designers have learned a lesson.
People used to complain about the way Python changes were breaking their code. So it was decided to restrict all the non-reverse compatible changes to a separate version called 3 and to stop breaking things in 2. That probably allowed Python to become more popular than it would of otherwise, but at the cost of a significant fork. So what are you going to do? Either way has downsides. And it isn't like developers real…
Seems like the best approach here is to not introduce breaking changes to begin with. Go has done a very good job at this. And AFAIK most of the breaking changes in Java have been the introduction of new keywords and have been relatively easy to manage.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#303Earlier 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,
Embracing pure technical churn is no ones job. That's why Python3 is viewed as a problem by so many. People embrace true technical innovation, which it is not.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#304Let's hope this will finally change the "compatibility with py3 is a feature" to "no py3 compatibility - no library" state of things. It's really surprising how stubborn some teams are.
It's time! It's really irritating in the scientific programming world at the moment because we've had some dependencies take years to get to Python 3 compatibility and are they're now being all holier than thou about it all. We couldn't even start doing the work until our biggest dependency (which we use in 90% of the code base) was ported to Python 3 and while that's been available for about a year, they weren't dis…
PySpark?
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#305Earlier quoted context omitted.
Automated tests is extremely beneficial for such cases. You should know that the code works before you deploy.
Easier said than done. This isn't the web world, things aren't so simple. How do I mock a temperamental motor controller responding to AT commands? I mean, I'm sure it's hard enough to replicate the oddities of their serial port parser, but the temperamental part is gonna be tricky. This is an embedded system I'm talking to, which is parsing bytes coming over a serial port in an interrupt service routine at 16 MHz wi…
I work primarily in embedded, so I feel you :)
One can separate the I/O code from the application logic, and do data-driven testing of the application logic. Use recorded data from real-life systems to build a (partial) model of the system, at least enough to test individual interactions or short sequences of interactions. Capture this data continiously in production systems, so that when an incident occurs it can be cut-and-pasted to form a new testcase. The latter is critical to build up a library of regression tests for those nasty things one had to find the hard way - so that at least it only happens once.
With this basis you can optionally go to hardware-in-the-loop testing, where some of the same testcases run with real hardware instead of fake responses. This should then be instrumented with neccesary sensors/code to be able to observe its behavior. This ensures that your mock and system stays in sync, and increases coverage for non-deterministic cases. At least one such system should be hooked up to your CI server to test every revision of the software, to catch issues early.
When building the next product, consider shipping the instrumentation neccesary for QA into all products. That way the testing system is closer to real system, and one can integrate self-checking, failsafes and error reporting in production systems. This can be used by final QA (before shipping), by engineers debugging on-site and as part of periodic (or continious) health checks on the equipment.
I've done such things for electromechanical systems, though nothing with a potentially-dangerous motor yet.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#306Earlier 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…
Most of CGI’s customers (if it’s the CGI I’m thinking of) are used to supporting software ecosystems like Fortran, Java, and COBOL for 20+ years on major releases. 10 years is “mid-cycle” comparably. When the IRS pays Microsoft millions and millions to keep supporting Windows XP, these “niche” organizations may be small in actual engineering persons involved but from a capital perspective extremely overweight.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#307Earlier 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…
Meanwhile I routinely use Lisp written before I was born (in 1986) that works out of the box in 2018. I’ve used Java packages (recently) from 1999. My company still uses python/pypy 2.7 and we see no compelling reason to upgrade. If there is any sort of upgrade, it will be off of python.
When, oh when will we ever finally unlearn "worse is better?" It's hard enough writing good code without having to fight your tooling (non-orthogonal, non-homoiconic, non-malleable, non-backwards-compatible languages, some with header files propagating changes upwards and breaking user code, and some with fascist type systems causing combinatorial explosions of containers and factories, ugh)
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#308Earlier quoted context omitted.
Mega large orgs have already moved, in some cases. They have the advantage of being able to throw significant resources into infrastructure to make switching easy.
I'm thinking about Google, Mozilla, Dropbox, etc. They still use a lot of Python 2.
Google created Golang and then created a tool to convert Python2 -> Go.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#309Let's hope this will finally change the "compatibility with py3 is a feature" to "no py3 compatibility - no library" state of things. It's really surprising how stubborn some teams are.
It’s not that surprising. People want to work on their tasks of interest. Smart programmers allocate some time for maintenance activity but py3 is a rewrite that is well outside the boundaries of normal maintenance. When the first thing you run has syntax errors and you might have to change almost every file to make any progress, it’s a rewrite.
And plus, many projects are maintained by people in their free time, often for free. Of course no one wants to spend a ton of free time redoing everything only to work apparently the same as before.
Re: Python 2 will be replaced with Python 3 in the next RHEL major release
#310Earlier quoted context omitted.
Automated tests is extremely beneficial for such cases. You should know that the code works before you deploy.
Easier said than done. This isn't the web world, things aren't so simple. How do I mock a temperamental motor controller responding to AT commands? I mean, I'm sure it's hard enough to replicate the oddities of their serial port parser, but the temperamental part is gonna be tricky. This is an embedded system I'm talking to, which is parsing bytes coming over a serial port in an interrupt service routine at 16 MHz wi…
Are you afraid of network security attacks to your embedded hardware? If not, then you probably don't care about missing security updates. What are you concerned about with python2.7 no longer being supported? Like, are you worried about getting python2.7 installed on a new piece of hardware five years down the road? I understand you dislike the tone from the python3 devs, but I don't know what you would like instead.