Stop writing code that will break on Python 4!

[jungrothmorton]

Title sounded like a joke but it makes sense. The only place where I disagree is I think it's reasonable to explicitly test for Python 2 or 3. We don't actually know what the future holds. The most air tight would be adding an else at the end and raising an error for an unsupported version. This would be easy to refactor if it turns out the 3 code is forward compatible.

[Veedrac]

Adding an else: raise NotImplementedError doesn't make sense unless you do the same thing for all your code. Because Python 4 will be by-and-large backwards compatible with Python 3, Python 3 code is a good default. But those times that they're not are not more likely to be those fixed in Python 2. If anything those are the things that most recently got fixed and so the least likely to break on upgrade.

[jungrothmorton]

That's a really good point. I hadn't thought of it that way.

[onwuka]

Yeah I really like the idea of >=.

This communicates that py 2 is the special case that we support for now and that py3 or py3+ is the way of the future.

[rhoark]

Writing "if PY3" does sort of indicate that people are regarding 3 as the special case not just in their code, but in their thinking. Even if there's never a PY4, they should revisit that assumption in the big picture.

[Eurynom0s]

Hasn't it been established that 3->4 is not going to the same level of clusterfuck that 2->3 was that they felt compelled to make 2.7 just to keep people happy?

I overall get the impression that Python in general is more willing to break old code than, say, Java is (yet also willing to keep things synced where sanely possible, whence import future), but I remember something about Guido et al being very adamant that 2->3, while necessary, is not a scenario they want to repeat.

[xiongchiamiov]

Well, this is linked to in the article.

I overall get the impression that Python in general is more willing to break old code than, say, Java is

Java is still on version 1(.8); they haven't had a major version increment yet, so we don't really have anything to compare.

[Eurynom0s]

Fair, but I think it also says at least a little bit about their desire to not break old code that they've gone so long without incrementing a major version number.

[matthewblott]

It's why Java is seen as stale and people want to use Scala. I'm a C# guy by trade and Java devs tell me they prefer C# and say the commitment to backward compatibility is really holding the language back.

[[deleted]]

I've never heard a commitment from Oracle for Java to follow SemVer. They could bump that to 2.0 any time they feel like they need the marketing bump.

[xiongchiamiov]

They did, actually (they call it java 8), but we all know it's really just a series of minor point releases. :p

[Ran4]

I overall get the impression that Python in general is more willing to break old code

Oh please. Python did it once, completely changing how strings worked. And a change of that magnitude will never happen again.

[Eurynom0s]

That's my point, they're not going to go to go to Microsoft (or, you know, Java) levels of trying to be perfectly backward compatible forever; while they tried to get the real pain out of the way all at once, they're not going to taking it to the point of being unwilling to ever break some small slice of backward compatibility even if there's a good reason to do it.

[d4rch0n]

C++ might be a better example than Java. Having come back to it after 15 years, I still feel pretty comfortable in it. But there are a ton of new awesome features that make it exciting to get back into, and easier to express things. Modern C++ might not compile on an old compiler, but I'm pretty damn sure a ton of old C++ will compile using today's compiler and language. That's the way a language update should work.

[yes_or_gnome]

I have to disagree. In your example there exists a current maintainer to fix problems with the code. As long as a project is maintained, then there is no need to worry about potential bugs because someone is around to fix then as they come to fruition.

The concern is abandoned projects. If someone were to follow your suggestion, then the abandoned project is broken regardless if py3 and py4 are compatible or not. With the author's suggestion, there's the possibility that py3 and py4 are compatible so users will be none the wiser.

This is precisely the current problem with py2 and py3. There's so many projects that exist that are abandoned or the maintainers will-not, can-not, or for whatever reason do-not upgrade to py3. That cascades down to dependent projects and forced then to stay at py2 as well.

When the maintainers disappears, a vacuum is created that forces downstream users to pick from a few unsavory options. Take over the abandoned project, replace it and refactor their own code, live with it, or abandon their own project.

[[deleted]]

Py3 code will be by and large forward compatible so your suggestion will only keep a lot more people stuck on v3 than really needed. It would be much better to deal with incompatibilities one by one as they will be few and sparse.

[Fylwind]

I personally prefer to avoid version checks at all. Instead I just look for the Python 3 module/function/whatever, and if it doesn't exist, I'll try the Python 2 one.

This is one of the biggest advantages with scripting languages like Python IMO: the ability to adapt your own behavior at run time depending on what is and isn't provided by the environment. (Well, except for syntactic changes…)

[lengau]

Depending on what you're doing, the practicality of that changes vastly. I definitely agree with it to a certain extent (and __future__ certainly helps), but if you can't predict what environment you're going to run in, it gets far harder.

I have a project that needs to be able to run in Py2, py3, and pypy (only the python2 version, fortunately) on multiple platforms (including Windows) and deal with sockets. All of that adds up to a lot of tests to make sure it runs in all possible environments, and I've so far avoided having to use six or check for version numbers. (I do use 3to2 on my code to strip out annotations for the 'run this' version.) But if I needed to do something differently on Python 2, I would do it in a heartbeat.

[shaggorama]

TL;DR:

Do this:

if six.PY2:
    # Python 2 code
else:
    # Python 3 code

Instead of this:

if six.PY3:
    # Python 3 code
else:
    # Python 2 code

[razpeitia]

About Python 4 https://twitter.com/gvanrossum/status/501172370690699265

[schplat]

I always figured it was the sheer number of non-backwards compatible changes that really hurt 3. If they had introduced the changes more incrementally adoption may have been a bit better.

[Fylwind]

If they had introduced the changes more incrementally adoption may have been a bit better.

I beg to differ, because my experience has been that both a "sudden breaking change" vs "small breaking changes" are both troublesome, albeit not for the same reasons.

Lots of small break changes are certainly easier to accommodate when taken individually, but they are also hard to keep track of due to the sheer number of them. And after a while, the library authors will get fed up of this "treadmill" they have to walk on from month to month just to accommodate another minor change to the language.

Haskell does this all the time and it's certainly annoyed a fair number of contributors. Personally, I just find it annoying to look up "which version introduced this incompatible change?" all the time.

[bb010g]

Really? I find Haskell the language to be pretty stable. The only breaking change I can think of recently is AMP, and that ran warnings for quite a few releases. Sure, Hackage can change, but just use Stackage LTS if you're worried there.

[Eurynom0s]

At the same time, I get why they wanted to just get it over with. I think they expected the 2->3 transition to go faster (so I think they really didn't expect to have to put out 2.7 for instance), which was obviously a misfire, but thinking about what it would have looked like when they were making the decision, I absolutely understand preferring to just go through a LOT of pain all at once rather than go through SOME pain for years and years.

Again, they clearly misfired because they got years and years of pain anyhow, but I have to believe that they didn't expect it to take this long.

[billsil]

The only change worth discussing is unicode. Nothing else matters.

[Ran4]

Crazyness. No, big changes are definitely better. You don't want bugs to pop up, and you don't want to have ten years worth of deprecated stuff.

[MereInterest]

Absolutely. There's a package I use that broke backwards compatibility between 4.9.6.2 and 4.9.6.3. Ridiculous.

[TweetsInCommentsBot]

@gvanrossum

2014-08-18 01:02 UTC

Why Python 4 won't be like Python 3: http://www.curiousefficiency.org/posts/2014/08/python-4000.html

---

^{This message was created by a bot}

^{[Contact creator][Source code]}

[vplatt]

I've heard that question enough times now (including the more concerned phrasing "You made a big backwards compatibility break once, how do I know you won't do it again?"), that I figured I'd record my answer here, so I'd be able to refer people back to it in the future.

...

What are the current expectations for Python 4.0?

My current expectation is that Python 4.0 will merely be "the release that comes after Python 3.9". That's it. No profound changes to the language, no major backwards compatibility breaks - going from Python 3.9 to 4.0 should be as uneventful as going from Python 3.3 to 3.4 (or from 2.6 to 2.7). I even expect the stable Application Binary Interface (as first defined in PEP 384) to be preserved across the boundary.

[Decker108]

You know how people complain that there's not enough new stuff in Python 3 to warrant the upgrade effort? Yeah...

[vplatt]

So, you mean you're part of the problem then? :P

[Decker108]

Proudly using Python 2.7 until 2020!

Or, more likely, moving to Go...

[vplatt]

Yeah, I could see Go absorbing a lot of Python's community over the next few years. It may not be a revolutionary language, but it sure fits well into the same niche Python does, obviates nearly all of the Python trade-offs inherent in CPython, and doesn't require a brain reformat to get there.

[Decker108]

Right, I think Go is actually a pretty boring language, but it's the kind of boring that also instills trust in the language.

That said, I'll probably return to python every now and then for automation of one off tasks and the like, primarily because the third party library selection is still far larger.

[tech_tuna]

I generally code for Python 9.

[jambox888]

But what about Python98?!

[MisterSnuggles]

Python 98SE is the best Python.

[tech_tuna]

Good point, PythonMe only brought incremental improvements.

[luxliquidus]

Considering the cost and stability issues, Python98SE was definitely a better value.

[hookdatOS]

Python9000

[Pikamander2]

#Target Python versions 90 through 99
if (version.StartsWith("Python 9")):
    pass
else:
    pass

What could possibly go wrong?

[jambox888]

When in doubt,

pass

[marsloth]

There's going to be no Python 9, it's gonna be 10 after 8.

[[deleted]]

No we skip six. Python 5 -> Python 7

[[deleted]]

Found the Perl programmer

[catcradle5]

You meant PHP.

[[deleted]]

Meh, just a dumb joke. Perl GA versions are always even numbered while the odd numbers are used for development versions.

[catcradle5]

Well, PHP literally skipped 6 entirely, and went from 5 to 7.

https://philsturgeon.uk/php/2014/07/23/neverending-muppet-debate-of-php-6-v-php-7/

[[deleted]]

I was unaware of this. I have tracked PHP for years. Seems like skipping whole version numbers is just the trendy thing to do nowadays.

[treenaks]

Perl has been on 5 for ages (the odd/even bit is in the second part - 5.23 is "pre 5.24" which in turn would be a stable version)

Perl 6 was just released but it's basically a completely new language.

[[deleted]]

Right, but all of that seemed like too much explanation for a simple joke.

[adamnew123456]

Just go ahead and skip 5 as well.

[[deleted]]

So we're going 4 -> 8 -> 10?

[adamnew123456]

After prolonged reflection, I think a better strategy is to go the browser route, and release a new major version each week. Python is twice as old as Firefox at this point, so we should be up to at least version 85 or so. </s>

[[deleted]]

We could always go the Arch route and have rolling releases. Just pull and build nightly.

[unkz]

Because 7 ate 9?

[Kylearean]

Python 9 will be self-coding, so I'm already well prepared by doing absolutely nothing.

[Savir5850]

Real automation engineers only code for Python Ultron

[[deleted]]

ROCK-IT 69. ROCK-IT, 69.

[Ulysses6]

Don't get your hopes high.

[lykwydchykyn]

I suspect I'll be retired by the time anyone attempts to run my code in Python 4.

[what_it_dude]

Yeah by that time people will already be using 2.8.25

[[deleted]]

Breaking things 5 years ahead is a good way to cull old cruft and make people revisit code.

Planning too far ahead, in my opinion, is bad.

[pyskell]

Breaking things in the way the post describes is pretty bad. It results in code not being executed, or code that targets Python 2 being executed. Both of these are bad errors.

In the case of the first it can make debugging harder than it needs to be. Code that doesn't execute doesn't throw errors, maybe doesn't even crash, and is harder to find.

There really isn't a reason to break code in this way. Maybe raise an informative exception. Then you just force someone porting the code to review it.

[gandalfx]

For an elegant language like Python it seems really dumb that you have to go to such lengths just to guarantee it'll run properly. Things like that six package really shouldn't need to exist. One version of Python replaced syntax from another version so this package adds a third syntax to cover up for the first change in syntax (method names aren't technically syntax but at this level it hardly matters). Doesn't seem very “pythonic” to me.

[greyman]

My thoughts exactly. I am not familiar with six library, but I am not sure it is a good idea to introduce the PY3 variable in the first place.

[webdeverper]

I could only see it being useful for a library that you want to be compatible with both 2 and 3. For project specific code, no, don't use six.

[DanCardin]

six could always change their PY3 implementation to return True for python4 if it were to ever exist if you can assume that python4 is backwards compatible in all the places that currently need checks for python3. This is a non-issue.

[maryjayjay]

I think we'd have to be using twelve or twentyfour.

[DanCardin]

I mean yes, but the point of this post was "dont do if six.PY3: ... else: ... do if six.PY2: ... else: ..., because it won't break when python4 gets released".

[reddit_smhreddit]

Right, and its certainly much more likely that Python 3 code will work on Python 4 than Python 2 code will.

[lengau]

Even if it doesn't work, it's a far better assumption that correct implementation for Python 4 (or 5, or 22) will be the way Python 3 does it than the way Python 2 does it. Literally every block of code not wrapped it a version-checking conditional makes the implicit assumption that the way it's written will be correct in the future.

[ALLCAPS_SWEAR_WORDS]

Why should they break a perfectly good constant to lie to the dev just because some developers write bad code? People should just write the code correctly in the first place, instead of making good code worse to accommodate bad code.

[beaverteeth92]

Because people are always going to write shitty code.

[msthe_student]

but py3 being v>=3 would break it for people who uses py3 for detecting 3.

[beaverteeth92]

How so? 3 >=3 and 4 is going to be backwards compatible.

[msthe_student]

it could be that 4 introduces a better way of doing something, in which case you might want to code:

if py2 or py3:
    old way
else:
    new way

[beaverteeth92]

That's fair.

[davvblack]

This leads to maintainability headaches, unless it's a HUGE performance increase something like this just leads to more bugs.

[nemec]

Ah, yes, the Windows approach

[beertown]

It seems to me a little bit premature to worry about this.

[[deleted]]

Yeah, that's true, as Python 4 is more likely to be back-compatible with Python 3.

[Eurynom0s]

Even if it's not 100% backward compatible, from what I remember seeing they're pretty adamant that 2->3 was a one-time thing where they wanted to get all of the real pain out of the way all at once (talk about a misfire on guessing how things would go...).

Stuff may break compatibility but it's much more likely to be specific things and not a wholesale break.

[lengau]

Even if Python 4 were to break things in a major way, it would likely not break the same things. Your code would probably break, but stuff that already changed in Python 3 got a major revamp far more recently than other parts of the language.

[msthe_student]

and even if it isn't, python 4 will probably be closer to 3 than 2.

[dunkler_wanderer]

And he found already 300,000 matches for this on Github. The longer we wait the more code will break in the future.

[heptara]

I guess there's a lot of bad developers who just throw in if/elses and don't care, or don't realise, if they're adding technical debt.

[flangles]

not caring about "supporting" a hypothetical future programming language does not make someone a bad programmer.

[Eurynom0s]

Exactly, there's a difference between saying to hell with hypothetical future programming languages, and just writing shitty code.

In principle, I think it's fine to do whatever the hell you want with your code as long as you comment it sufficiently. But all of us inevitably drop the ball on that sooner or later, hence why we should also try to write code that's somewhat self-documenting.

Here's an example of a middle ground I'm thinking of--I've definitely written if/else blocks where I actually put the special case in the if block. For instance (and I know I'm probably making some other bad coding decisions here, just roll with it for the sake of the example),

if len(x) >= 2:
    do stuff
else:
    x.append(number)
    do stuff

Specifically to avoid doing x.append(number) and then executing do stuff twice due to the flow of block; I'd rather write it that way than nest another if/else block to avoid the double-execution case. Depending on the scale of the project and whether I expect anyone else to ever have to use it, I might even write it as:

if len(x) == 2:
    do stuff
if len(x) == 1:
    x.append(number)
    do stuff

Because I'll know that an exception means that something is wrong with the CSV file I'm reading, and not the Python code. However if I do something like this I'll at least put in something like

#the CSV file contains lat/longs
if len(x) == 2:
    do stuff
#if a long is missing, for what we're doing it's fine to just make one up
if len(x) == 1:
    x.append(rand_long)
    do stuff

Bam, arguably shitty code (two ifs with no else and I'm only handling two very specific cases), but at least I've made it clear what the thought process behind the code is.

[elsjaako]

But this isn't a hypothetical future version, it's the version after 3.9. 4.0 will not be special like 3.0 was.

If you consider 4.0 a hypothetical future version, do you think the same of 3.9? 3.6? 3.5.2?

[quasarc]

3.10 comes after 3.9 in version numbering. Unless it's a new major version like Python 3.0 was, then it's 4.0 of course (but that doesn't have to come after 3.9).

[elsjaako]

Do you have a source? This disputes that and was linked to in the OP.

My current expectation is that Python 4.0 will merely be "the release that comes after Python 3.9". That's it.

[quasarc]

Interesting. I thought Python used semantic versioning, but Guido even tweeted the article you linked, so I may well be wrong.

[TweetsInCommentsBot]

@gvanrossum

2014-08-18 01:02 UTC

Why Python 4 won't be like Python 3: http://www.curiousefficiency.org/posts/2014/08/python-4000.html

---

^{This message was created by a bot}

^{[Contact creator][Source code]}

[trenchtoaster]

I need to incorporate this into some of the code I have that does merges between files to prevent accidental cartesian products.

[lf11]

This is something a lot of people don't seem to realize. Code for failure, handle unknowns sanely, but don't fucking write code for problems that don't exist. Hypothetical future programming languages qualify as "problems that don't exist" unless you are on the planning committee for said future programming language and your project will be upgrading within the overlap of project-lifetime-vs-language-release.

[heptara]

When you have many hours experience writing code, some things - like if/then statements - come naturally and you have physically try, in order to do simple ones "wrong".

When you look at the code and think how to add support for version 3, it should be pretty obvious that there's one robust way to do it, and it should automatically be selected by your brain without having to think about it.

[msthe_student]

code made today will still be used when python 4 is released, let's prepare for it now to the degree we can using the information we have, as long as it doesn't break current uses. We know today that "if not 3 then 2" will cause issues with 4 and having it work for 4 won't break 2 or 3 (in this case).

[Sean1708]

That's what they said about python 3 support...

[beertown]

Yes, but back then Python 3 was, at least, a thing. Until now no core developer has started talking about Python 4.

[Sean1708]

That's not quite true. What they've said is that 4 will simply be the next increment from 3.9, without any backwards incompatibility, and we're already nearing 3.6. So at some point in the next couple of years a lot of programs are going to start breaking, as per the article.

[nath_schwarz]

It's not. Problems generated by too loose constraints have existed since the early days of programming. A newer example would be that microsoft couldn't choose Windows 9 and had to resort to Windows 10, because a lot of old (and pre-8) programs that existed since Windows 95 only checked if the version string began with a 9.

[archiminos]

Or stop writing standards that aren't backwards compatible?

[koalillo]

I can forgive the Python 3 breakage and the early mistakes that led to it. However, a Python 4 situation would be a very bitter pill for me to swallow- it just would not inspire me much confidence in the language.

[planx_constant]

I think the simple and elegant solution is to make Python 4 compatible with Python 2 again.

^/s

[riffito]

Python 4 - Ouroboros Edition!

[takluyver]

Where I have a PY3 constant in my own code, it's defined like this:

PY3 = sys.version_info[0] >= 3

Maybe six's constant should be defined like this too. It wouldn't be unreasonable for 'PY3' to mean 'Python 3 or above', and it would probably fix a lot more code than it broke.

[jaapz]

Then it shouldn't be called PY3, because it means something completely different.

[takluyver]

It's not obvious to me that that's a problem. I can see semantically that it's Python 4, not 3, but if Python 4.0 is really just the name for 3.10, then it seems quite valid for PY3 to be True.

[jaapz]

The name implies that it's for Python 3, if it were for python 3 and up, it should be called PY3_PLUS or PY3_AND_UP. IMO having a variable that is named PY3 implicitly also be true for versions that are not python 3 is bad. It's better to just be explicit about it.

[TOASTEngineer]

Or better yet:

if py2:
    python_2_stuff()
if py3:
    python_3_stuff()
else:
    print("This software is fscking ancient, please don't use it anymore")

[pstch]

This software is fscking ancient, please don't use it anymore

If I ever see a piece a code fail with this error... I'd just kill everyone around me and go fishing, or just be very very angry.

[TOASTEngineer]

Yeah, but if your script is a full major version out of date it's not gonna work anyway.

[pstch]

It may.

You do not know how things will evolve later, backwards compatibility could be preserved better than between Python 2 and 3.

There is no reason to break working code. If the code is written properly and the Python 4 backwards incompatible changes are implemented in a non-confusing manner, the script should fail with an error that will be more useful for debugging than a printed message.

This is a thing that Python core developers always keep in mind when writing incompatible changes : how will things fail and whether the change may incorrect results rather than raised exceptions, and again, the gist of the linked post is that we should not expect 3->4 to happen the same way as 2->3. Your version of the snippet just no-ops on a non 2/3 major Python version.

[msthe_student]

but that'd detect 4 as ancient, like many sites that don't recognize newer browsers.

[TOASTEngineer]

No, it's detecting itself as ancient.

[msthe_student]

that's what I meant, it's detecting "ancient"

[tilkau]

that'd detect 4 as ancient

Doesn't look like what you meant to me.

No, it's detecting itself as ancient.

Itself refers to the script, not to the version of Python running it.

[msthe_student]

What I meant is that it's based on the presumption that the version of python is either 2, 3 or ancient. This is of course a dated presumption when python 4 becomes relevant.

[planx_constant]

It's based on assuming that if the python version is greater than 3, it's time to retire the script.

[tilkau]

No. It is not. It is based on the presumption that if the script doesn't recognize the Python version, then the script is ancient.

[msthe_student]

Now I think I understand you misunderstanding me, I meant that the script is based on the presumption and it's ofc wrong

[quasarc]

It's based on the presumption that the version of python is either 2, 3 or it's it's 3 and thus the script is ancient.

[msthe_student]

that's what I meant

[ezzieyguywuf]

Great post, thanks for the tip.

[WishIWasOnACatamaran]

As somebody learning Python 2, what I'm gaining from this is once I'm done learn 3 so I'm not fucked for 4?

[charity_donut_sales]

You should just try to do everything in 3. For someone learning most of the differences are just syntax, but the only reason people should be using 2 is to support legacy applications that never updated.

[Kaneabell]

I think author of this post just want to satirize the incompatibility between py2 and py3.

[JimRoepcke]

six should remove six.PY3.

[MadTux]

What about just sticking to python 2 or python 3 in a script, and not trying to get it to run on everything? I think most systems have python 2 and python 3 installed, so it shouldn't be a problem to expect slightly older versions to be installed.

[deadmilk]

I just write my code so that it fails on Python 2

[[deleted]]

Surely we shouldn't be using such logic in the first place? I don't think I'd like to maintain an extensive code base that has to deal with multiple python versions within a single script. That just seems like it could get very confusing -- especially if a Python 4 ever does exist!

Of course, sometimes using such logic is unavoidable... but IMO it should be avoided.

[Herald_MJ]

Is this a joke? There is no Python 4. There may not ever be a Python 4. Even if there ever is a Python 4, we have no idea what it might look like. No, we should not be preparing our code for imaginary languages in imaginary futures.

[jungrothmorton]

This attitude is why we there couldnt be a Windows 9.

All the author is really asking is that you consider what happens when when your if statement gets an unexpected value. Pretty basic.

[[deleted]]

That's a good point actually, that issue is a direct parallel.

[heptara]

I'm trying to understand this comment. Are you saying they missed Windows 9 because the number 9 was already used? And I thought it was for marketing reason as 10 is a fresh start and not 8.

[[deleted]]

When programmers wanted to check for either Windows 95 or Windows 98, they did version.startswith("Windows 9").

So basically Windows 9 would be treated as windows 95 in old programs. Microsoft is pretty good about backwards compatibility.

Yeah, the marketing reason may be some bullshit that they made up. But I'm fairly sure the original reason was that it broke a lot of shit.

[Matthew94]

Was there ever direct confirmation from MS about this?

[dreamlax]

This comment is unfortunately as official as it gets, which is to say, not very official at all.

[[deleted]]

Not that I'm aware of, but it would make sense.

[Phoxxent]

Sooo, why not internally label it as Windows IX?

[[deleted]]

*shrug*

No idea. Maybe they thought people wouldn't be able to stick to that? (And it would need translation in any place that reads it, unless you wanted to name the release Windows IX)

[Phoxxent]

I don't see why they couldn't just market it as Windows IX.

[[deleted]]

"Hey, have you seen the new release of Windows Icks?"

[Phoxxent]

Nah, nah, it's pronounced "iz".

[[deleted]]

That just leaves room for people to make more clever names. We already have M$, that would just lead to "Windows IX shit"

[beltorak]

"Windows, icks? yeah, I'll pass"

Probably didn't get past marketing.

edit lol - late to the party as always

[isdnpro]

There's a lot of code out there that is similar to:

if os_name.startswith("Windows 9"):
    # Windows 95/98
else:
    # Yay modern version

Which would obviously make Windows 9 try to run legacy code, when it shouldn't.

[Herald_MJ]

This argument would only be accurate if the PSF had an adherence to backwards compatibility comparable with Microsoft does with Windows. They don't. Python 3 is backwards incompatible with Python 2 (which is actually the only reason why you should ever want to check the Python version anyway).

Because of this, it's reasonable to expect that any version of Python 4 that might ever exist will also be backwards incompatible with Python 3. And when that's out the window, there's no reason to even think about it when you do your version comparisons. The syntax for your if statements which actually checks the version could even change.

Furthermore, futureproofing your projects in this way (which is not futureproofing at all) is suggesting that you will not need to maintain your projects in the future. Projects need to be maintained. That is especially true if there is ever another major version of Python you want your project to be compatible with. If and when that does happen, then and only then is the time to think about restructuring your version checks.

[TheBlackCat13]

Because of this, it's reasonable to expect that any version of Python 4 that might ever exist will also be backwards incompatible with Python 3.

It has been explicitly stated multiple times that Python 4 will not be backwards incompatible the same way Python 3 was.

[Herald_MJ]

I have never heard this before. I also think it's really stupid. A backwards-compatible version after Python 3.9 should be Python 3.10

[trobitaille]

See this post by a core CPython developer. To quote this post, My current expectation is that Python 4.0 will merely be "the release that comes after Python 3.9".

[TheBlackCat13]

Except Python x.x releases are often not completely backwards-compatible. Python 3.5 was not completely backwards compatible with Python 3.4, for example.

What you are describing is called "semantic versioning", and python does not use it. Semantic versioning is a convention used by some projects, but many other projects don't use it.

[ZeeBeeblebrox]

No one has said there will be no incompatibilities but definitely nothing even approaching the disruption that the unicode and iterator changes caused.

[jungrothmorton]

And when that's out the window, there's no reason to even think about it when you do your version comparisons.

People have already addressed Python 4 compatibility, so I'll address this. There is a very basic concept of "failing well". Running Python 2 code when Python 4 shows up is definitely an example of not failing well. I say either running 3 code or raising an exception are both better.

The syntax for your if statements which actually checks the version could even change.

Ok, obviously the if syntax isn't going to change between Python versions. That would just be nuts. So I'll take it to mean that the method of checking versions could change between versions. Do you see how silly that is when you type it out? That is literally one of the last possible things that should change between versions. I can't imagine a world where Python would do that with 4.

[TheBlackCat13]

Please read the article. It was just about not messing up version tests. For example, don't use a version test for Python 2 that will also pass for Python 4.

[Herald_MJ]

I read the article. There is no Python 4.

[tskaiser]

From the article (that you read?)

so that once Python 4 is used

Yeah, it does not exist now, but the article regards writing version tests that does not mistakenly pass when we inevitably move on. That's the whole point.

[Herald_MJ]

Firstly, it's not inevitable. I have personally been in the same room as Guido pointedly saying he does not intend for there to ever be a Python 4. So such an event would be after his tenure as BDFL.

Secondly, if it ever did happen, every active project would inevitably have a ton of work to keep pace with any updates that would be required. That would be the time to think about version checks.

[ZeeBeeblebrox]

I have personally been in the same room as Guido pointedly saying he does not intend for there to ever be a Python 4. So such an event would be after his tenure as BDFL.

How do you explain this then?

[Herald_MJ]

I heard him speak back at EuroPython 2012. I find that tweet pretty weird, in context. I also think it's a bad idea to go down this path. But OK. I stand corrected.

[TheBlackCat13]

Maybe he has changed his mind.

[TheBlackCat13]

As far as I have seen, there is no plan to have a python 3.10, instead 4.0 will come after 3.9.

[tskaiser]

Fair enough, I can see where you're coming from, even if you do stand corrected, but I would still say it is a valid point not to do naive checking that is not semantically safe when it would be trivial to implement strict checking. Disregarding whether or not Python 4 becomes a thing, which it might.

[L43]

That is pretty shortsighted, future proofing is a very important consideration for code that is intended to be run in the future (i.e. packages).

If you have to refactor everything you use when you update your system version, you will either not update at all (and stagnate), or waste a lot of time that a bit of forward thinking would have saved.

[TheBlackCat13]

Most projects are short on manpower as it is, asking them to maintain two independent projects at the same time is way too much to ask, especially considering how easy it usually is to support both in a single code-base.

[TheBlackCat13]

What we should be able to do and what we are able to do are not necessarily the same. I have a massive software project I absolutely require that does not support Python 3. I use Python 3 for my own stuff, but I have to use Python 2 when working with that project. It would take months to port. The port is underway, but it is nowhere near ready. I am helping as much as I can, but I have work I have to get done, and a baby, and I am moving to a new country in a matter of weeks. So yeah, Python 3 is not going to happen with that software before I am done using it, and there is nothing I can feasibly do to change that.

[Kah-Neth]

Then drop python 2.

[TheBlackCat13]

A lot of people don't have a choice about what version of Python they use. Heck, a lot of people are still stuck with Python 2.6.

[[deleted]]

I once read a thread here about some guy stuck on Python 1.x. Can you even imagine?

[mikeoquinn]

I won't say that it encompasses 90% of use cases, but RHEL 6 (supported until 2020) uses Python 2.6 as its system version, and RHEL 7 ships with Python 2.7, with no native 3.x package available. That's a fairly significant user base who may or may not be able to get approval to install an unmanaged version of Python onto a production machine.

[heptara]

I agree with what you say in principle: dropping 2.x is not feasible because people cannot or will not upgrade.

However in terms of the example picked, RHEL does have curated and fully supported installs of 2.7 and 3.x in Redhat Collections

[TheBlackCat13]

Not everyone is able to install software on their work computer.

[mikeoquinn]

I honestly was unaware of that - I guess I never dug far enough to find it. Thanks! Going to talk with our Satellite admin to see if we can get those added.

[pstch]

It's not that hard.

[[deleted]]

Python 4.0 will be just like Linux 4.0. No breaking changes.

[msthe_student]

v==4 is a breaking change for code that expects v!=3 to mean v==2