8 ms·
Good riddance! The fact that we're still supporting Python 2 at all in 2021 is madness.
by wmichelin 6y ago
Good riddance! The fact that we're still supporting Python 2 at all in 2021 is madness.
- GNU_James 6y agoFriendly reminder that entire scientific community runs on Python 2 legacy code and nobody will rewrite it to Python 3.
- jennyyang 6y agoAt some point it will be selectively rewritten if it's important enough.
- awakeasleep 6y agoI love/hate this type of tautological yet provoking statement
- ironmagma 6y agoIn what sense is it tautological? I can think of a lot of things that are important that won’t get done, healthcare improvements being one. Software on the other hand is typically fluid enough that someone will rewrite it.
- ozzy6009 6y agoIf it wasn't selectively rewritten, it wasn't important enough (to be selectively rewritten).
- kortilla 6y agoBecause the bar can be effectively slid around justifying that it was/wasn’t important enough if it does/doesn’t get rewritten. It’s as meaningless as telling someone they will achieve their dream if they want it bad enough.
- ironmagma 6y agoI think it’s slightly more meaningful, because not all dreams can be achieved. If software isn’t getting ported from Python 2 to Python 3, it almost certainly isn’t because it’s too hard to do.
- hprotagonist 6y agonot in my neck of science python (biomed/neuroscience; computer vision). We've been substantially more aggressive about moving to 3 than other python neighborhoods! Look at the top projects at https://python3statement.org/ https://python3statement.org/, for example. Hell, numpy 1.20.x is dropping support for anything below 3.7! I started doing science python in 2015 on 3.5.x, never had to touch 2.x at all.
- GNU_James 6y agoThat's why people move to crappy conda / docker. To keep those Python 2 environments running. There no new people to rewrite tons of software.
- leephillips 6y agoThere's another reason for using containers or pretested distributions. I just wrote an article for LWN about SciPy¹. To get what was supposed to be a clean install of the newest release, I created a virtual environment and used Pip to install the SciPy components. It was broken out of the box. IPython did not work because a module that it depends on, that does tab completion, had been recently upgraded and was incompatible with it. I mean it crashed frequently, not just that it didn’t do tab completion. To get a working system, I had to install an older version of the library. So people seek solutions that avoid the dependency hell that comes from maintainers releasing things at will, with nobody testing the combination of things that they nevertheless market as “SciPy”, which is supposed to be a bunch of stuff that works together. And whenever I install anything from the Python world, I am amazed when it actually works without the need to spend hours with Google or staring at sources trying to resolve conflicts. One of the many nice things about Julia is that their package system works. So yes, once you manage to put together a working installation, you naturally want to encase that precious thing in the bubble of some kind of container, to protect it from an upgrade of some piece that will break everything. If you work with a lot of Python things, you may have a dozen copies of the same libraries, and a handful of Python binaries, taking up space on your drive. The concept of dynamic linking was supposed to save us from this. But the haphazard habits endemic to the Python community seem to have left us with the worst of all possible worlds. [1] https://lwn.net/SubscriberLink/842964/f7e2e5006c5efe36/ https://lwn.net/SubscriberLink/842964/f7e2e5006c5efe36/
- Q6T46nT668w6i3m 6y agoThis is absolutely untrue.
- geofft 6y agoI mean, huge chunks of the scientific community run on MATLAB or Fortran. (Also... are you actually managing to get new students to install Python 2 on their laptops, somehow? And no enterprising undergrad is just like "I will just make this work on Python 3 because that's easier"?)
- joshuamorton 6y agoEhh, I absolutely did that. Heck, for a class I reverse engineered a robot's bluetooth control api because coding up computer vision was easier in python than in matlab (which had a provided "SDK" that some TA had written in years prior). I spent less time doing that issue than it took to debug a missing comma on the end of a line in some matlab code (for a different assignment in a later class) that led to some incorrect matrix operation and completely failing code. I do not like matlab.
- willis936 6y agoI think it’s a matter of experience. I’ve used MATLAB for nearly a decade and can whip up optimized bit banging, data acquisition, and signal processing code in a matter of minutes. When I try the same in python I spend days trying to figure out what the “right” solution to something is, try 3-4 options, find the issues with each, and by that point I’m burnt out and tell myself it isn’t worth it to try to replace MATLAB.
- cozzyd 6y agoand MATLAB and Fortran are fully supported, so I'm not sure what the problem is?
- canofbars 6y agoNo one will do it until it becomes painful enough to not do it. Killing support in all of the tools is the only way to make it happen.
- the_local_host 6y agoNo one will do it after support in the tools is killed off either. People will use the last versions of the tools from wherever they can get them, and workarounds for any issues that are discovered will become part of the folklore surrounding the code.
- canofbars 6y agoThats fine too, at least its no longer bogging down software maintainers since they can just tell people they do not support py2
- willis936 6y agoSweeping cat puke under the rug is not the same as cleaning cat puke off the floor. Having software maintainers to tell their users “get bent” does not fix the user’s bugs or security exploits.
- coliveira 6y agoSoftware was supposed to make people's lives easier, no to be a form of torture!
- orf 6y agoThat’s absolutely not true though.
- tootie 6y agoI inherited a ton of python 2 code. Am I screwed?
- awakeasleep 6y agoImagine if your car broke down monthly, and you could afford to fix it, but buying a new one would put you into an uncomfortable amount of debt. Screwed? No. Terribly inconvenienced, yes. This is assuming you have enough other stuff to do that you cant afford the “debt” of migrating the python2
- tcbasche 6y agoHaving worked with a huge Python 2 codebase recently, it's fine[1] but just becomes painful regarding dependencies. It just means you'll never have the latest versions of things. My advice would be to gradually port what you can using six (https://pypi.org/project/six/ https://pypi.org/project/six/) [1] Fine in the sense that, the code will still work
- wruza 6y agoAnd the fact that we still periodically trap the efforts of thousands of smart people and bury it alive is insane. When told that something will only live 5 years we turn it down. When told that something 5 years old is now obsolete, we celebrate. The definition of insanity is doing the same thing over and over again and expecting a different result. (c)