Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

91–100 of 237 posts

Re: Code that will break in Python 4

#91
post #58

Version checks are also the reason why we have Windows 10 and not Windows 9 because people checked whether the OS version started with "Windows 9" (for Windows 95 and Windows 98).

The source to that information (as far as I can tell) is a Reddit post claiming to be from a Microsoft developer. I've worked with programmers dumb enough to write such a version check, so I totally believe this might be true, but I'd love an official source.

[deleted]

Re: Code that will break in Python 4

#92
post #4

Has there actually been a statement that python 4 will be backwards compatible to python 3?

I don't have any links but I know there have been statements by core devs that, when/if there is another major version of python being developed, there will be an upgrade path to make the 3->4 transition much better than the 2->3 transition.

Yeah, they pretty much botched the 2->3 transition. I would love to see a 4 that included a viable 2->4 transition with semantic versioning until then. But Guido&Co are going to do whatever the hell they feel like doing, community be damned. Py2.7 will be forked and going strong long after 2020. Actually 2020 will probably be a Python renaissance when the cruft, incompatibilities, gil, no jit, etc can finally be addressed without the Guido mafia. 2.8 will be what 3 should have been, using deprecation for dated syntax and gradual introduction of new features. Python is open source. There will be a 2.8 regardless of whether Guido is involved.

Re: Code that will break in Python 4

#94
post #42

As someone that uses Python intermittently it seems like there's still a lot more tutorials, Q&A, and documentation for v2 on the internet than for v3. When searching for info about python it's often difficult to tell if I'm looking at something for v2 or v3, and when I can tell it's usually for v2.

Usually when it's hard to tell that's because it applies to both. The differences between the two are really not that large.

Re: Code that will break in Python 4

#96
post #54

Reminds me of when Linus tagged Linux 3.0 and it broke a bunch of peoples code due to their bad version checks. Linux 2.x had been going for about 15 years.

Yep, that change broke CrashPlan's JNI module that handles inotify on Linux because they were checking only the minor version number.

I had to write a shared library to override the call and inject that into the CrashPlan process so it'd be happy. Fun times.

Re: Code that will break in Python 4

#97
post #27

Earlier quoted context omitted.

... thats stupid. Semver isn't that complicated, and everyone understands what 3.10 means.

Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991. Not having precognition made it difficult for Python to adopt SemVer, and now that they have versioning practices in place there needs to be more than "I like SemVer" as a compelling argument for them to change. Especially since there are reasonable people who ha…

The argument for semver is obviously "you should be able to tell if there are breaking changes between two versions from the version numbers", not "I like semver". You may or may not be persuaded by it, but that's the point of it.

Re: Code that will break in Python 4

#98

Earlier quoted context omitted.

I have nothing to back this up other than my increasingly unreliable memory, but the semantics of SemVer goes back further than 2009. Maybe it wasn't formally written out, but as far back as the 90s that XX.YY.zz could be translated as XX == major changes, breaking changes for APIs, reworked UI for end-user apps. YY == some new functionality, no breaking/major changes. zz == bug fixes. It probably goes back further t…

There were a lot of projects informally using what semver defined, but there were also a lot of other popular versioning schemes. Odd minor = unstable version, even minor = stable version used to be pretty popular and is still used by a few projects. The main thing that helped make SemVer the default assumption was package managers that baked it into the dependency resolution, as until then a project's versioning sch…

Well, baking it into dependency resolution is a response to the fact that figuring out if there were breaking changes in any given update becomes intractable as your dependency tree/graph gets large (and multi-levelled), when each dependency uses it's own versioning scheme, no matter how comprehensible they are individually.

Re: Code that will break in Python 4

#99
> We don't really know yet what Python 4 will look like, but we can be pretty sure that the transition from Python 3 to Python 4 will be a lot smoother

Doesn't compute.

You can't say you don't know anything about Python4 and immediately follow up with suggestions on how to program for it.

And if you really want to be consistent, at least:

    if (python2):
      // python 2
    else if (python3):
      // python 3
    else:
      raise "I have no idea what I'm doing"
At any rate, given the time lapse between Python releases and how catastrophic version migrations have been so far, it's safe to say that by the time Python 4 comes out (if ever), we will all have long retired from development.

Re: Code that will break in Python 4

#100
post #39

Earlier quoted context omitted.

All my code uses from __future__ import __all__

Silly you, time travel has existed for quite a while by the time python 7000 is released. No import statements are required as everything you need is, and always has been, included from the beginning of the ages. Somehow all of those libraries are still smaller than my slack desktop app.

> Somehow all of those libraries are still smaller than my slack desktop app.

https://en.wikipedia.org/wiki/List_of_burn_centers_in_the_Un...

Post reply on HN