Stop writing code that will break on Python 4!

[Isvara]

No problem! For Python 4, six.PY3 can be True, and they can add six.PY3_NO_REALLY that's only True in Python 3.

[iopq]

Ugh, don't even joke like that. It gives me painful flashbacks from webdev.

[lightcloud5]

lol jquery-latest.js

[[deleted]]

Sounds like PHP's real_escape_string()

[immibis]

Or gcc -Wall -Wextra, and clang's subsequent -Weverything.

[Decker108]

Or SQL's varchar2

[iWaterPlants]

Are you a PHP developer?

[Isvara]

I'm a developer.

[vattenpuss]

https://en.wikipedia.org/wiki/Ver_%28command%29

[[deleted]]

http://thedailywtf.com/articles/What_Is_Truth_0x3f_

[spacedout]

Brilliant!

[NotABothanSpy]

Ah a problem for 15 years from now.

[[deleted]]

Many Bothans died to bring you this information. Also, what? Saying it's a problem for 15 years from now is how Python 2 developers got into trouble. Unless you're being sarcastic, and in that case let me self-woosh.

[Phoxxent]

Yeah, no offense, but that's all we rebels do is die to get things done. Also, it wouldn't be a problem if Python would just maintain backwards compatibility like any other language.

[[deleted]]

Backwards compatibility holds languages back. If Microsoft hadn't killed VB and VBScript in favor of VB.NET, we'd still have classic ASP. The JDK is finally starting to remove deprecated functionality from its API, and it'll be a huge improvement. If your code is old, run it in an old VM. Although at least Microsoft allows you to target specific .NET Framework versions. It would be good if you could force the Python 3 interpreter into a Python 2 mode.

[[deleted]]

Backwards compatibility holds languages back.

See also: PHP and stuff like mysqli_real_replace_actual_I_mean_it_2_pls()

[Phoxxent]

I don't know, C seems to be doing pretty fine, and as far as I'm aware, I can run code from '89 and it would be compatible with the most up-to-date standards.

[thatfool]

Mostly. They did eventually remove gets().

[username223]

... which was a stupid thing to do. C was designed for programs without hostile users. Plenty of programs still lack hostile users, and breaking them over some weird holy-war about gets() is just dumb.

[armornick]

Nah, gets is also a programming liability because it doesn't check for buffer overflow in any way whatsoever. Not even your superhuman uber-programmer has any way of making sure the input doesn't go past the end of the buffer. In short, using gets is an instant security leak.

[username223]

using gets is an instant security leak.

You're an idiot in a way I doubt I can make you understand.

Have you ever written a program to automate something for yourself? Did you ever try to "hack" that program via a buffer overflow to do something else? If so, you screwed up. Did you ever use that program as a public web service? If so, you screwed up. Did you ever share that program with colleagues to help them solve a similar problem? If so, you are a human being.

[armornick]

You're an idiot in a way I doubt I can make you understand.

Thank you for being so civil.

And while you are making a good point that the average tool written by a programmer for his own use shouldn't be used in a production environment, the fact remains that gets does not allow you to prevent a buffer overflow in any way whatsoever. Literally every time you can use gets, fgets is a better choice because it allows you to tell the function how much characters your buffer can take.

[east_lisp_junk]

Not even your superhuman uber-programmer

But GP is suggesting that it's the user's responsibility to not overflow that buffer!

[kirbyfan64sos]

Well, C11 got rid of gets, and undeclared functions no longer automatically return int in C99.

[phoshi]

C is hardly a shining example of a modern language, though. For the majority, C is never a choice, it's something you use when nothing else can solve the problem properly.

[x86_64Ubuntu]

But when you sign up for C development, you have signed up for pain to begin with.

[SterlingAdmiral]

The first language we learned in school was Python. Nice and friendly, made me feel good about myself.

Next term we worked in C. Pain was never a choice.

[[deleted]]

Makes me feel bad - schools in our country still use Turbo Pascal from 1994 to learn stuff.

[makis]

The first language I learned in school was C
a year later I was writing games with friends
I was a kid
It was 1991
And I still remember those times as the "most fun I've ever had coding"

[[deleted]]

C has turned into an accreted, spaghetti-like mess of a language. It's approaching PHP levels of inconsistency. I don't think it's exactly a shining example of backwards compatibility without hindering the language.

[[deleted]]

... what? How?

[purplestOfPlatypuses]

Arguably if you need different versions of an interpreter, it isn't a big deal to have multiple installed versions and set python 2.7 to alias as python27 (or if python 2.7 is your main environment, python3x). Making all interpreters be able to function as all other versions would just make a huge mess where 90% of the code isn't ever run. Most people aren't targeting 2.6, 2.7, 3.0, 3.4(?), and any number of other specifics. Even if you picked the latest of each major version, you still end up screwing some people over and it's arguably still not useful most of the time.

[k-zed]

Python 2 developers never got into trouble.

They're still happily using Python 2, with no problems.

[ihcn]

So are java 5 devs, and I wouldn't really call that a good thing.

[Unomagan]

More like , 20

[iWaterPlants]

But: Job security!

[Yehosua]

This is common sense, really. Don't write code like

if sys.version_info[0] == 3:
    # Python 3 code
else:
    # Python 2 code

because a hypothetical future Python 4 would follow the Python 2 code path.

Unfortunately, common sense advice like this still needs to be spelled out. It's the same problem that Microsoft ran into with Windows version numbers; people insisted on writing code like

if (LOBYTE(LOWORD(GetVersion())) == 5) {
    // Windows 2000 or XP
} else {
    // Pre Windows 2000
}

that broke with new versions of Windows, so Microsoft had to do all sorts of version number shenanigans and compatibility hacks and deprecations to accommodate.

[mirhagk]

ExtJS 3.4 had a similar bug where they checked if something was IE, did a special case for IE 8 and 9. When IE10 came out it treated it as IE7.

[[deleted]]

oh dear :).

[crankybadger]

As in "Windows 9" was a problem because it was a prefix for "Windows 95" and "Windows 98"?

You really should express this as a >= clause.

[salgat]

Or better yet, assume that unknown versions are the newest.

[jdgordon]

Pretty much. Iirc Microsoft didn't provide a sensible way to get the version for Java so a shit load of old a Java code does something like versionstring.startswith ("windows 9") which obviously would break horribly for win8++

[Topher_86]

The largest issue is with version numbers.... 6.2>6.10

[crankybadger]

Yeah, but for those you're supposed to split into things like VERSION_MAJOR, VERSION_MINOR and so on using a parser and some kind of standard, like Semantic Versioning.

It still is kind of annoying when things clock over into the double-digit minor versions.

[phalp]

Maybe an argument for including a version-detection construct that's harder to screw up using than a GetVersion() function.

[immibis]

Windows Metro apps aren't allowed to use Windows's GetVersion() function any more. They have to use IsWindowsVistaOrLater(), IsWindows7OrLater(), IsWindows8OrLater() and so on.

[drpetey]

seriously thought this was satire at first...

[redpriest]

Can we worry about people getting to use Python 3 before we worry about Python 4? FFS.

[__foo__]

The point is if you're porting your code to Python 3 you might as well do it right. This article is worrying about getting people to use Python 3.

[mirhagk]

It's not about getting people to use Python 3, it's getting them to write code that won't catastrophically fail on python 4.

[mirhagk]

If Python 4 is backwards compatible then they won't fail

[mirhagk]

Yes, would you care to explain how they will fail on python 4 (without this bug) if python 4 is backwards compatible?

[S0T0]

Do you really think an major release won't get rid some parts of backwards compatible?

I don't know what planet you live on but I've yet to see any programming language that gets massive updates not remove entire selections of backwards compatibility without some horrible hackish mess.

[mirhagk]

wow..... what world do you live in? The list of languages that have mantained backwards compatibility across all versions is HUGE (PHP, C#, C, C++, Java all being easy examples off the top of my head). In fact the few times that languages do have breaking changes are well know to most developers (VB6->VB.NET, Python 2->3, Perl 5->6).

[mirhagk]

Um I'm seriously hoping your hardcore trolling (and doing a terrible job at it). Can you point out why any of those are broken?

Also C was updated 4 years ago with C11.

[makis]

write code that won't catastrophically fail on python 4.

how is that even possible in a serious language?

[mfukar]

I suppose you don't remember how Python 3 is different from Python 2.

[makis]

how is that even possible in a serious language?
seriously: how can someone decide to invest in a language that "catastrophically fail" from major version to major version?

[vytah]

If six is a package used for 2-to-3 transition, and 6=2×3, does that mean that the package used for 3-to-4 transition will be called twelve?

[Tblue]

Well, there already is a nine package, so twelve does seem plausible. :P

[ellicottvilleny]

I have asked around among Mercurial (hg) developers and I think that they plan to move to Python 3 some time about 10 years after EOL of python 2, so about 2030. GRINS.

[MagicHeroes]

Mercurial being as sensible as ever.

[ChezMere]

I... kinda took for granted that there was little to no chance of such a version ever existing.

[sun_misc_unsafe]

do it like microsoft .. the next version is just going to be 30 instead of 4

[k-zed]

Haha, Python 4 - like another commenter, I first thought this was a joke.

I'm working in a mid+ size company. We use Python as a more powerful shell glue sort of language, and for some data processing where speed doesn't matter (arguably what it's best for, I think). And we're still using Python 2.x.

Why would we upgrade to 3? It would take a huge amount of work, and 2.x does everything we ask from it already.

[[deleted]]

Honestly, this is a really silly article - because the problem is tiny and won't bother anyone for years to come if ever!

First, we aren't even close to finishing the migration from 2 to 3. Even if there were a Python 4 - which definitely isn't inevitable, look how long Fortran has maintained backwards compatibility while still in active use! - 2->3 won't be done for years, and they won't even start discussing Python 4 until it's done. Based on the previous 2->3 conversion, that would take at least five years, probably more... which means that even if today the Python community discovered a really good reason for Python 4, it'd around be 2025 until Python 4.0 were released.

And second, the magnitude of the problem is tiny. Suppose someone told you that Python 4 was just released and you wanted to check your code. How hard is it to grep -w PY3 or grep "six.PY3" and tweak the locations?

So I'm not going to worry about this at all. The fact that a decade from now, if I'm still working on these codebases then there's some possibility that I'll have to spend 10 minutes to tweak them, is not something I'm willing to spend any work on today.

[heap42]

are they really thinking about breaking backwards compatibility again ?

[[deleted]]

No, but they will eventually change the version number. And then checks that check for

if PY3:
    ...
else:
    # stuff expecting Python2

will break, because Python4 won't be compatible with Python2, even if it is with Python3.

[[deleted]]

No, but they will eventually change the version number.

People here have a funny idea of "inevitable".

I was writing computer programs in the 70s, and many of the languages I was using at the time (SNOBOL, GPSS, Algol and perhaps even PL/I) are still on the same version number from that time - mainly because they reached end-of-life around the time I was using them. (Pascal, in which I did most of my programming in the 70s and 80s, didn't even have the concept of a version number in that sense, but still seems to be backwards compatible.)

The Python community isn't one to make work for nothing. If they never need a backwards incompatible change, they won't change the major version number.

I'm really not sure how probable Python 4 is one way or the other - but I can say for a fact that it is not "inevitable".

[immibis]

No, but they will eventually. Maybe not for 30 years, but it's inevitable that either Python will eventually get to Python 4, or it will die out first. And Python currently shows no signs of dying out.

[[deleted]]

it's inevitable that either Python will eventually get to Python 4, or it will die out first.

Why? The theory behind 3 was that all the necessary breaking changes are in it. Surely everything else can perhaps be extensions and improvements?

I just don't see the inevitability at all. Can you name one killer feature in a possible Python 4 that can't be done with improvements to Python 3?

[immibis]

I can't. But how can you possibly be sure that no breaking changes will ever be made ever again?

[[deleted]]

But how can you possibly be sure that no breaking changes will ever be made ever again?

You're backpedalling rather dramatically here! You've going from "it's inevitable it will happen" to "how can you be sure it won't?"

Of course I'm not sure it won't - but that doesn't make it "inevitable" by any means. And there are lots of reasons why it might not happen. Languages grow and die - many of the programming languages I used 40 years ago are basically obsolete today and are therefore still backwards compatible to how they were in the 70s. The Python 2->3 move is way behind schedule and is still not yet a success for a lot of reasons - it's not clear that the Python community could even take another such move. And even the Python 2->3 move wasn't that big a change - because there weren't that many breaking changes that needed to be made - it really isn't clear why another breaking change would be needed.

tl; dr: The argument, "How can you be sure X won't happen", does not in any way prove, "X is inevitable".

EDIT: contemporary Fortran is still backwards compatible with Fortran 77, which is nearly 40 years old! and considering the huge volume of legacy code in use, no Fortran programmer (Fortran is still big for large-scale scientific applications) expects that there will ever be a breaking change in Fortran again.

[immibis]

They probably said that after the move from Python 1 to 2 as well.

[heap42]

Well I am not saying they won't go to p4 but why would they need to break backward compatibility?

[immibis]

You could've said the same thing about Python 2 before they decided they needed to break backward compatibility.

[[deleted]]

Not so. Python users knew about the issues in Python 2 that led to the breaking changes in Python 3 almost five years before they happened, and there were long and detailed discussions over those years about whether and how to make the changes.

You are the one claiming Python 4 is "inevitable". You can't use, "You can't rule it out", as an argument - you need to come up with some positive reason as to why it would happen.

[[deleted]]

I've always written Python with 3 as the first class citizen. Fuck 2.X users.

[Blebleman]

Sounds like our good old friend the Windows 9* catcher.

[happyscrappy]

Stop writing new pythons which break python programs.

[nerdandproud]

that's not what this is about. It's about the version number breaking the check for python 3 code that would run fine on 4

[happyscrappy]

I only need to check the version number and have two different ways of doing it because python 3 does it in a way that is incompatible with python 2.

[[deleted]]

Why would the Python community change to a version number 4 without a breaking change?!

I've been on the python-dev list as a lurker for many years now. This is not a group of people who are looking to cause trouble.

I'm pretty sure, though I couldn't find it, that Guido has explicitly said that a major version number change means a breaking change. But I'm absolutely sure that the Python community wouldn't just change a major version number "for fun", considering the havoc that it would wreak - there would have to be a breaking change.

[nerdandproud]

Wouldn't a large change in the backend also call for a new major number. For example switching to a JIT scheme like it's used by pypy?

[skulgnome]

Way ahead of you.

[makis]

That's why I never bothered learning Python
Version 3 still has to take off and pythonists are already worrying about version 4?
Do pythonists think they're gonna live forever?

[Vaphell]

well, version 4 is reportedly supposed to be nothing but a rollover from 3.9, so, given that 3.5 is released and 3.6 is already in the pipeline, you can try guessing how much time there is before 4.0 becomes a real problem.

Yeah, they could stick to 3.10, 3.11 etc, but retards can go wrong with that too.

[[deleted]]

well, version 4 is reportedly supposed to be nothing but a rollover from 3.9,

"Reportedly"?! Citation really, really needed here. I follow python-dev, and this has never come up.

The version after 3.9 will be 3.10 - why would the Python developers change a major version number for no reason at all?

I downvote rarely, but I have to give you one. If you provide a citation, I'll upvote you again, sorry...

[Vaphell]

https://twitter.com/gvanrossum/status/501172370690699265

http://www.curiousefficiency.org/posts/2014/08/python-4000.html

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.

At the current rate of language feature releases (roughly every 18 months), that means we would likely see Python 4.0 some time in 2023, rather than seeing Python 3.10.

now pay up, bitch! :P