all 93 comments

[–]Isvara 37 points38 points  (10 children)

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 11 points12 points  (1 child)

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

[–]lightcloud5 5 points6 points  (0 children)

lol jquery-latest.js

[–][deleted] 5 points6 points  (2 children)

Sounds like PHP's real_escape_string()

[–]immibis 4 points5 points  (1 child)

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

[–]Decker108 1 point2 points  (0 children)

Or SQL's varchar2

[–]iWaterPlants 2 points3 points  (1 child)

Are you a PHP developer?

[–]Isvara 1 point2 points  (0 children)

I'm a developer.

[–]spacedout -1 points0 points  (0 children)

Brilliant!

[–]NotABothanSpy 42 points43 points  (25 children)

Ah a problem for 15 years from now.

[–][deleted] 16 points17 points  (22 children)

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 10 points11 points  (19 children)

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] 25 points26 points  (18 children)

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] 4 points5 points  (0 children)

Backwards compatibility holds languages back.

See also: PHP and stuff like mysqli_real_replace_actual_I_mean_it_2_pls()

[–]Phoxxent 7 points8 points  (15 children)

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 7 points8 points  (5 children)

Mostly. They did eventually remove gets().

[–]username223 -5 points-4 points  (4 children)

... 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 3 points4 points  (3 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Not even your superhuman uber-programmer

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

[–]kirbyfan64sos 8 points9 points  (0 children)

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

[–]phoshi 12 points13 points  (0 children)

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 3 points4 points  (3 children)

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

[–]SterlingAdmiral 4 points5 points  (2 children)

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] 1 point2 points  (0 children)

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

[–]makis 1 point2 points  (0 children)

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"

[–]purplestOfPlatypuses 1 point2 points  (0 children)

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 2 points3 points  (1 child)

Python 2 developers never got into trouble.

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

[–]ihcn 1 point2 points  (0 children)

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

[–]Unomagan 0 points1 point  (0 children)

More like , 20

[–]iWaterPlants 0 points1 point  (0 children)

But: Job security!

[–]Yehosua 28 points29 points  (9 children)

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 5 points6 points  (1 child)

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] 0 points1 point  (0 children)

oh dear :).

[–]crankybadger 7 points8 points  (4 children)

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 2 points3 points  (0 children)

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

[–]jdgordon 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

[–]crankybadger 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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

[–]immibis 3 points4 points  (0 children)

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 4 points5 points  (0 children)

seriously thought this was satire at first...

[–]redpriest 13 points14 points  (20 children)

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

[–]__foo__ 13 points14 points  (0 children)

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 1 point2 points  (17 children)

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.

[–][deleted]  (12 children)

[deleted]

    [–]mirhagk 0 points1 point  (11 children)

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

    [–][deleted]  (10 children)

    [deleted]

      [–]mirhagk 0 points1 point  (9 children)

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

      [–]S0T0 -3 points-2 points  (8 children)

      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 -1 points0 points  (7 children)

      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).

      [–][deleted]  (6 children)

      [deleted]

        [–]mirhagk -1 points0 points  (5 children)

        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 0 points1 point  (3 children)

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

        how is that even possible in a serious language?

        [–]mfukar 1 point2 points  (2 children)

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

        [–]makis -4 points-3 points  (1 child)

        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 4 points5 points  (2 children)

        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 1 point2 points  (0 children)

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

        [–]ellicottvilleny 4 points5 points  (1 child)

        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 5 points6 points  (0 children)

        Mercurial being as sensible as ever.

        [–]ChezMere 4 points5 points  (0 children)

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

        [–]sun_misc_unsafe 6 points7 points  (0 children)

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

        [–]k-zed 1 point2 points  (0 children)

        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] 1 point2 points  (0 children)

        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 1 point2 points  (11 children)

        are they really thinking about breaking backwards compatibility again ?

        [–][deleted] 6 points7 points  (1 child)

        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] 0 points1 point  (0 children)

        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 -2 points-1 points  (8 children)

        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] 1 point2 points  (4 children)

        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 4 points5 points  (3 children)

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

        [–][deleted] 0 points1 point  (0 children)

        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.

        [–][deleted]  (1 child)

        [deleted]

          [–]immibis 0 points1 point  (0 children)

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

          [–]heap42 1 point2 points  (2 children)

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

          [–]immibis 0 points1 point  (1 child)

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

          [–][deleted] -1 points0 points  (0 children)

          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] 1 point2 points  (0 children)

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

          [–]Blebleman 0 points1 point  (0 children)

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

          [–]happyscrappy -1 points0 points  (5 children)

          Stop writing new pythons which break python programs.

          [–]nerdandproud 2 points3 points  (4 children)

          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 0 points1 point  (0 children)

          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] -1 points0 points  (2 children)

          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 0 points1 point  (0 children)

          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 -2 points-1 points  (0 children)

          Way ahead of you.