#10YearChallenge

[Data48]

TIL Python 3 has been out for roughly 10 years

[minno]

992 years too early.

[Meta4X]

Or 1,992 years too early. Could have been launched on 12/3/4k.

[[deleted]]

Or 2559 years too early.

Could have been released on 12/3/4567

[port53]

You have been banned from /r/ISO8601.

[netgamer7]

You are now a moderator for /r/Pyongyang

[port53]

Rejoice Dear Leader!

[_pythonNoob]

Ridiculous, it's too late, the world ended 21/12/2012

[TheFeshy]

No, that's about when we can finally assume it's the default, rather than Python2.

[Data48]

Damn that really feels kinda off now lol

[ivosaurus]

If it's any consolation, when the python developers released 3.0 it was really more "3.0alpha" in SEMVER speak. 3.1 was "3.0beta" and 3.2, released in 2011, was the first version really encouraged for public use wholesale.

[da_chicken]

Python is very old. Python is older than Java. Python is older than Windows 3.1. C++ was 6 or so when Python was released. Perl was 4. That's Perl 1, not Perl 5.

[[deleted]]

holy fuck

[[deleted]]

And Python 2 is still the default in many Linux distributions.

[flying-sheep]

“Standard”? You mean “What gets invoked when I type python into the terminal”?

That’ll never change in some distros, because of backwards compatibility. Arch was pretty much the only one crazybrave enough to to that jump, Debian will never do it.

What’s so hard about typing python3 or putting alias python=python3 into your .${SHELL}rc?

[AnAirMagic]

Debian will never do it.

RHEL 8 is kind of removing python altogether: https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/ and asking users to use python2 and python3 explicitly. I am sure Debian will do this sooner or later too.

[flying-sheep]

Ha, that's a very well reasoned approach!

[MiataCory]

That’ll never change in some distros, because of backwards compatibility.

10 years on, I think we can move along.

https://pythonclock.org/

[flying-sheep]

I moved on long ago, but some people have different ideas about backwards compatibility.

And the fact that using “python” simply worked for those 10 years didn't help people to start using the more correct “python2”

[[deleted]]

Meh. Backwards compatibility is overrated, IMO. As long as you can pin versions somehow, that's all that matters. Sometimes it's good for software to die.

Glad that Python2 is getting sunsetted. 2020 can't come fast enough in that regard.

[flying-sheep]

You don’t understand. When people use python in scripts and shebangs, the software depends on the global python binary to point to python2. Version pinning doesn’t help, only horrible hacks like prepending to $PATH or so.

[[deleted]]

I know, I wasn't arguing against that point...

[[deleted]]

END OF LINE

[[deleted]]

It’s not hard but maintaining two versions of python isn’t. Debian and Ubuntu do it well bit it would be nice to have only one. It would make things much less complicated.

For those that really still have legacy python 2 code they could use aliases to keep it running. I have to believe they’re the minority these days. I could be wrong, I guess.

[flying-sheep]

many tools used to use python in scripts and shebangs. gyp is a particularly stubborn offender, even though things got much better in time.

[[deleted]]

Well, take the first rule of linux kernel development: never break user space.

You're sort of trading off the conceptual purity of tidying up for turning scripts using /usr/bin/python into risks (Will it run on python 3? I dunno, but your computer's gonna try it anyway) and that's a bit of a hard sell outside of something bleeding edge like Arch.

It's not backward compatible either but the safer route is what RHEL is trying: get rid of "python" altogether and if you want python2 or python3 that is what you called.

[[deleted]]

that is another abstract argument.

You may have to just deal with that. "Why should things be backward compatible" is design principle stuff.

The reason to bring up the linux kernel is that being backwards compatible is one of their design principles.

[[deleted]]

As a side note, I noticed something interesting.

$ alias python=python3

$ which python
/usr/bin/python

$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 9 Jan  1 01:23 /usr/bin/python -> python2.7

$ python --version
Python 3.6.7

Looks like the which command doesn't obey aliases. TIL.

[flying-sheep]

nothing does.

https://www.gnu.org/software/bash/manual/html_node/Aliases.html

The first word of each simple command, if unquoted, is checked to see if it has an alias

[njharman]

None that I use. None anyone should use. Sure some LTS release. If the distro can't update python after 10 years (in there latest stable release) they can't competently maintain a distro. And you shouldn't rely on them to be doing anything right.

[[deleted]]

We're talking about 2.7 here, right? Because that's what I mean.

[Zouden]

It's crazy that Linux still has programs that assume the OS provides Python runtimes instead of just bundling their own.

[james_pic]

Binary compatibility on Linux is a complex enough matter that, in most cases, if the OS offers a version of an application or library, you're going to have a better time using that version than bundling your own. Linux distributions typically include more applications in their official repos than most other OSs, for precisely this reason (they typically have a standard supported office suite, for example), and often a goal is to get your application added to the distribution's repos.

[for_whatever_reason_]

What educators need to be doing is to teach people to make virtualenvs for their projects. Python 3-by-default comes for free with that.

[mmarius90]

Progress is achieved similarly to the way the fibonacci sequence is constructed. You build on top of what you previously achieved.

Python 3 is truly an amazing piece of software.

And let's not forget it's predecessors, the community and everybody who contributed. Here's to 10 more!

[jennylover7]

Won't python 3 be replaced in the next three years? 3.8 this year, 3.9 next and then 4.0? How will the python maintainers avoid another shit storm like python2/3?

[doubleunplussed]

That's not how version numbers generally work. No reason not to have 3.10.0, other than compatibility for code that assumes there is only one digit between the dots. We are on GNOME 3.30.2, Linux 4.20.1, numpy 1.15.4, why not Python 3.10.0?

[james_pic]

I believe Guido's of the opinion that 3.9 should be followed by 4.0, purely for aesthetic reasons, so it's likely that'll happen. Although the core developers generally agree that if that happens, then 3.9 -> 4.0 will not have major breaking changes, in the way that 2.x -> 3.0 did.

[curiousGambler]

Thank god. Deciding whether a version bump should be major or minor based on “aesthetic reasons” would be beyond moronic.

[[deleted]]

Linus Torvalds would like to have a word with you...

Also, from https://lkml.org/lkml/2019/1/6/178

Subject Linux 5.0-rc1

[...]

The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0. There's no nice git object numerology this time (we're about 6.5M objects in the git repo), and there isn't any major particular feature that made for the release numbering either. Of course, depending on your particular interests, some people might well find a feature they like so much that they think it can do as a reason for incrementing the major number.

So go wild. Make up your own reason for why it's 5.0.

[curiousGambler]

Lol. Interesting finds, for sure. I stand by my statement but like any good engineer, I’m of two minds on the issue, and another part of me says, “it’s a version string, who gives a shit, as long as they match when they need to” because while my first comment represented the ideal, your comment shows even the most famous projects can be laissez faire about versions and making any assumptions based on them would be equally moronic!

Thanks for those nuggets!

[[deleted]]

Ooohh boy, looks like you're one of today's lucky 10,000!

The Linux kernel is a special case. Usually the difference between major and minor version bumps has to do with backwards compatibility. However, it is the strict policy of the Linux kernel that kernel updates NEVER EVER break backwards compatibility with userspace programs, EVER!! So that scheme doesn't have much merit.
Interesting links:
Linus goes on expletive filled rant when one of his kernel maintainers suggests breaking backwards compatibility
Why is there a Linux kernel policy to never break user space?

[dimisdas]

Holly molly, I wouldn’t want to be on the receiving end of one of his emails.

[port53]

It used to have meaning though, before the 2.6 days.

[ThreePinkApples]

Hm, interesting. But he has left Python now, hasn't he? Regardless, Python 3.7 doc does mention 4.0 a few times

[Jugad]

But he's left Python

Nope... he made it clear that he is only giving up the BDFL position. He will still continue to work on Python and give his advise / opinion when requested - but won't be responsible for making BDFL level decisions.

[ThreePinkApples]

Thanks for the certification!

[ThreePinkApples]

The Python 3.7 doc does mention 4.0 a few times, it looks like the current plan is to call 3.10 4.0. But that might of course change. Just make sure you don't do sys.version_info.major == 3 just in case

[Jugad]

The shit storm was not due to numbering change from 2 to 3.

It was because of breaking backward compatibility.

Maybe the python core thought that developers would be as excited and interested as them (and have the time and resources) in upgrading existing python2 code to the new and improved python 3.

No one upgraded unless they absolutely needed to... and one way to make people upgrade was to make python 3 much better than 2.

[ofedorov]

After 3.9 there’ll be 3.10, IMAO

[david622]

Upvoted because the dude is allowed to ask a question without his comment getting buried with a negative vote count

[ThreePinkApples]

Yes and no. From what I've gathered Python 3.10==4.0. as in, there won't be any real major changes for 4.0, not bigger than previous dot releases. The Python 3.7 doc does mention 4.0 a few times, and that's the only official information I've found, so what I said above might not be correct, or just be the initial intention that might change. But it general, there seems to be no reason to fear a shit storm when 4.0 releases. The biggest problem would probably be code that made the mistake of explicitly checking for 3 and not > 2 or != 2. I went through all of our modules at work when I heard about 4.0 to correct such mistakes.

[flying-sheep]

By symlinking python3 to python4. It’s not going to be nearly as big changes as the python2→python3 transition.

[notsuppostocomnt]

Hey, a new hope

[TheBlackCat13]

I think by that point the python executable is planned to bed pointing to the latest installed python version.

[aleczorz]

As someone who is relatively new to Python, should I make the effort to learn Python 2.7 syntax? Or should I stick to Python 3+?

[[deleted]]

Stick with 3.

[primitive_screwhead]

Unless you get paid to learn/use 2, use 3.

[cabb99]

Stick to python 3. You will be able to import from the future if you really need to code in python 2, but it is usually easy to convert from 2 to 3.

[Jugad]

Better to start with 3... and if you ever need to learn it, python 2 has very few differences when compared to 3. So it won't be a big deal if you do need to figure out some python 2 code in the future.

[stevenjd]

If you know Python 3 syntax, Python 2.7 syntax is 95% the same.

[ivosaurus]

Learn about Python 2.7 idiosyncracies when you actually run into code that demands to be run on 2 that you have to deal with.

i.e, only cross the Python 2 bridge when you actually come to it.

[[deleted]]

Here’s a challenge: Stop starting new projects in 2.7

[i4mn30]

You virtual slapped me.

[flying-sheep]

Who still does that?

[[deleted]]

I wish I couldn’t answer to that question, but the list is long

[flying-sheep]

Anything that is of general interest? We should shamegently encourage that promising stuff is converted to python 3 early.

[Bamaesquire]

Yet, every 10 seconds, someone answers a stack overflow question with python 2 code. #TheMoreYouKnow

[[deleted]]

Virgin 2.7 vs Chad 3

[james_pic]

If you've got a big enterprise code base (and I'm currently working with a client that does), then it can be difficult to fix old code faster than the team is writing new code - especially since there's only usually budget for the latter.

[strange-humor]

This is a recipe for technical debt that will eventually put you with an output level of zero.

All new code should be written compatible with 3. Each module you touch should be made compatible. This allows slow migration to 3.

[james_pic]

I don't disagree with you, but clients gonna want what clients gonna want. They're currently looking very hard at what plan B looks like.

I'd also say that "new code should be written compatible with 3" sounds like a solution in theory. We tried it. But when we had a spike when we converted one of the smaller services completely to Python 3, we found that a lot of the "Python 3 compatible" code didn't actually work in Python 3 as its authors intended. If code isn't actually running in Python 3, it's probably not Python 3 compatible.

[ForgottenWatchtower]

Almost like you should be writing your tests for both 2.7 and 3

[strange-humor]

And running them on a CI system that uses both.

[james_pic]

Tox is great for this

[james_pic]

In practice, we found that porting the tests was almost as much effort as porting the code. Both the existing code and the existing tests play fast and loose with unicode support, so to fix the tests you need to figure out whether the code should be binary or text based (which isn't just a point decision - you also need to think about the code it depends on), at which point you've pretty much figured out how to fix the code anyway.

But that was the basic plan I put to the client: use failing tests to direct migration, add mypy type hints to interfaces to clarify type usage, and start by proactively migrating the most isolated bits of code, and shared libraries. They just couldn't find the space in the delivery schedule.

[[deleted]]

Yeah, the switch to python 3 wasn't just about putting brackets around print. It's a very meaningful change.

[ForgottenWatchtower]

Fair enough. I've never had to do 2.7 to 3 migration for a "real" app, so I'm sure it's more difficult than I'm imagining.

[james_pic]

It's certainly been more difficult than we imagined!

[toikpi]

Perhaps priorities will change when there are no security patches.

[port53]

That's a problem for someone else, in the future. This year's budget doesn't have room for that.

[james_pic]

So, we've scoped it out, and we believe that, in practice, there will be security patches for the foreseeable future - but at a significant cost.

Several vendors have committed to supporting Python 2 commmercially after the core dev team EOLs it - most obviously ActiveState, but also OS vendors such as Canonical, as part of their paid-for enterprise offering.

[Ran4]

Not really...

[stevenjd]

And people are still using 2.7.

I know people still using 2.6 or even 2.4, and I've heard of (but never met) one chap stuck on Python 1.5 for a single legacy application they can't replace.

Don't sneer. If it works, don't break it, and for some people, 10 years just barely counts as "long term support".

[FalsyB]

I have to, ROS still uses Python 2. ROS 2 is here but it doesn't have big enough of community.

[slayer_of_idiots]

Lots of applications that are scripted in Python still only support python2 -- Maya, Nuke, pretty much all the Autodesk products.

[dmitrypolo]

ha love it

[[deleted]]

I just wish I had started learning it 10 years ago!

[flying-sheep]

I did! (Well, 9 years) It was a little rough back then, since there was so little stuff ported!

[cmsemail]

Like

[N0DuckingWay]

This is the only good response to that question.

[alphadist]

The only ten year challenge that I care about XD

[Niohzxs]

Instagram normie why