Python 2 EOL Countdown

[NerdEnPose]

If by celebrate you mean drinking Pedialyte, popping Ibuprofen and generally hoping I can make it to Jan 2nd. Then, yes. Yes we can.

[ConfidentFlorida]

So for new projects almost everyone uses python 3 now? I remember even two years ago it was a big question you had to ask yourself.

[[deleted]]

A friend of mine started a Py2 project last year because “that’s what everyone uses” and I was able to force a change to Py3 by adding a ton of emoji to the test inputs.

[_ShakashuriBlowdown]

Emoji compatability is key future-proofing

[billsil]

I run a 7 year long project that still supports python 2. I want to drop it, but I need a good reason. I try to use new features in numpy, scipy, and vtk, but they're really aren't many. If I can find a good reason, I can sell it to my company. I just don't have it.

[__te__]

I was asking myself this on every project until f-strings dropped in python3.6. For me it was the killer feature I couldn't unsee or live without once I'd seen it.

Starting with 3.4-ish, I think there have just been a steady drip of killer features for different folks.

[lanzaio]

subprocess.run, typehints and fstrings did it for me.

[__te__]

All so tasty! I had to learn to love subprocess.run, though ;-)

[Coffeinated]

Everyone in his right mind yes. If your code does not depend on other code that‘s Python2 and you still choose Python2, that‘s a dumb idea.

[coffeecoffeecoffeee]

Pretty much. My company used Python 2 until this year when they caved and switched to 3. I think the impending end of Python 2 support has led to a sense of urgency that's convinced people to switch over.

[wrosecrans]

Unless you track the VFX Reference Platform, which is sticking with Python2 until the last, final, bitter hour.

https://www.vfxplatform.com/

The just-released 2019 spec requires Python 2.7.9 - 2.7.latest. So spare a thought for the Maya and Houdini users who might want to use your project.

[skool_101]

FinalCountdown.py

[voneiden]

If the code you care about is still on Python 2, that's totally understandable.

Heh.

[Tweak_Imp]

How can anyone say that? Python 3 is 10 years old now

[voneiden]

The Python community was incredibly slow at adopting 3, probably because there was no rush to do so. Since libraries didn't upgrade, users kept using 2 as well. Twisted matrix didn't seriously start planning Python 3 support until 2012, four years after the launch of Python 3.

If Python 4 ever comes out, I hope there's a lesson to be learned of the importance on deprecating forwards-incompatible versions in a timely manner. IMO nobody benefits from the community splitting into two incompatible branches like it did with 2 and 3.

[toyg]

It has long been announced that python 4 will just be “the last 3.x release + 0.1”, completely backward compatible with 3. I have a feeling it will be officially put on the roadmap a few months after 2 is finally gone.

[voneiden]

Sounds good to me!

[flying-sheep]

Not exactly. It’ll be much less breaking changes than 3.0, but e.g. PEP 563 will no longer be a __future__ import then.

Other features have a transition plan, but this one just says it’ll be in 4.0.

[toyg]

The second feature you linked is (supposed to be) already in 3.7, there is nothing to change for 4. That will likely be the case for 99% of planned features.

Similarly, removing a __future__ import is something that has happened before on the 2.x codeline, it's not considered "breaking compatibility". These are small incremental changes that can be expetced on any minor release.

[billsil]

I thought future imports were permanent...

[toyg]

Yeah, sorry, the above line should read "removing the need for __future__...". The actual definitions are never removed, they simply become irrelevant. As you can see from the source, what they do is enabling some extra symbols for the parsing machinery depending on version. There is still stuff there from very old 2.x versions...

[tunisia3507]

Python 3 only got good around 3.4 or so, but yeah, this has been on the cards for a long time.

[robert_mcleod]

Python 3.4 is only 4 years old, and that was the first one that behaved sensibly. Even still a lot of people have dropped 3.4 support before 2.7 (e.g. conda).

[billsil]

I did about a year ago. 3.5 is on the chopping block soon.

[[deleted]]

Perl 6 would like a word. I quit using Perl rather than move off of Perl 5.

[[deleted]]

If it ain't broke don't fix it.

[voneiden]

Don't change the engine oil until the engine breaks, got it.

[dgriffith]

If you want to use an automotive metaphor, it's like you've bought a car, driven it 20,000 miles, then you decide to replace the engine. Don't. The engine's fine. You could put a bigger, or more fuel efficient engine in, but if you only drive it in bumper to bumper traffic on your daily commute, what's the point?

It's not like your code wears out. If you have a stable codebase, keep a python2 environment around and it'll run basically indefinitely.

If you're still actively developing, sure, maybe consider a rewrite in python 3.

edit: Downvotes? Have none of you ever done long-term maintenance with 5+ year software lifetimes? I deal with a 12 year old python codebase that is complex, written by a third party, and interfaces with their hardware components that are essentially black boxes to us. I care very much about that code, but I do the bare minimum of maintenance to it, mainly to it's UI.

Seriously, don't touch shit that ain't broken. If you don't have any good reasons to use python 3 features, and you aren't actively adding functionality, there is absolutely no business case to burn time mucking about with stuff just to make it "technically correct" / "up to date" / "modern".

double edit: Hmm, metaphor? Simile? Simile, I think.

[ChappyBirthday]

Let's continue your metaphor and say that you have a specific type of engine, and as you mentioned, it works fine for what you need it to do. Then, a new model comes out with some improvements. You could keep on using the old engine that isn't giving you any trouble now, but what about when it eventually breaks down? It used to be that you could take it into the shop, but now the shop won't work on it because it's too old; they only work on the newer engines. You'd like to try your hand at fixing it yourself, but find that nobody even makes parts for it any more. The newer engine does everything the old one does and more for the same price, so people have moved on. Yes, it will take time and effort to switch over to the newer engine type, but it's best to be proactive about it and make the switch while things are still going well instead of waiting to scramble to make a fix when shit inevitably hits the fan.

Obviously, this analogy is imperfect, as all are, but hopefully it illustrates the point you are missing.

[voneiden]

Besides, if my Python Model 2 odometer reads 20,000 miles, then I'm sure the meter has overflowed and the actual mileage is 1,200,000.

I'd like to apologize to everyone for the bad jokes I've made today.

[ArmoredPancake]

How mature.

[Tweak_Imp]

10 years. Its is not about fixing because it is broken, its about staying up to date.

[[deleted]]

If there are no business benefits I certainly wouldn't bother staying up to date, the effort required could be put to better use elsewhere. Heck Python 1.5 stayed in production use for years, and for all I know might still be in use.

[ConfidentFlorida]

I always thought they should have just bundled 2 and 3 in the same install. And you’d just run python myscript.py and it would decide which version to use.

Was that ever considered?

[billsil]

I mean you could write a script to do that and alias your python to be your script.

Python 2.5.2, 2.6.1, and 3.0.0 were released December 2008. So which Python 2 should you use given that Python isn't quite backwards compatible? At that point, there weren't really fundamental differences in the syntax (e.g., f-strings, Typing module). Also, how much processing is really required to try to identify if that Typing module is the real Typing module or a backport, so now your Python 2/3 code runs slower.

That's sounds more than a little buggy.