Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

Post reply on HN
Print view View original

81–90 of 237 posts

Re: Code that will break in Python 4

#81

Post by Practicality »

orf wrote: post #66
Grue3 wrote: post #30

There isn't all that much code written for Python 3 to care about backwards compatibility. IMO Python 4 should be: - backwards compatible with the latest release of Python 2 - contain all features of Python 3 in some form I think this will result in a very speedy adoption. In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with…

> IMO Python 4 should be: > - backwards compatible with the latest release of Python 2 > - contain all features of Python 3 in some form I'm lost for words.

Python 4 should be magic.

Re: Code that will break in Python 4

#82

Post by untog »

zanny wrote: post #63

As someone who has had to pressure some of the most backwards companies to update their software, it is going to be the most horrible of pains, in the same way Linux 4.0 is right now, to have a pointless major version increment. Lawyers, suits, and investors shit themselves seeing that number go up when previous increments actually meant something, so when it now no longer does, it just makes my life a living hell fo…

Semantic versioning is taking versions seriously. Far more seriously than arbitrary version numbering does, anyway.

Don't get me wrong, I do understand your frustration. But "previous increments actually meant something, so when it now no longer does" is just totally incorrect. Previous increments were an attempt at bundling together a series of unrelated changes into a 'thing'. What that 'thing' is varied wildly between organizations and products. Semantic version increments are breaking changes, pure and simple.

Re: Code that will break in Python 4

#83

Post by jfoutz »

chubot wrote: post #18

Well Python doesn't use semantic versioning, but if it did, there would probably be no Python 4.0. It will just be Python 3.15, 3.16, ..., 3.99, 3.100, ...

just take the emacs approach and drop the leading digit. i'm hoping to live to see an emacs 2.0 release someday...

Re: Code that will break in Python 4

#84

Post by s73v3r »

andrewingram wrote: post #22

Is there a reason why any future syntax changes cannot be handled using transpilers in the same way it's worked for the JavaScript community? Such transpilers do exist for Python, but they never really saw much use, is it because 3to2 came along too late, and for a long time we only had the option of 2to3? ie once future syntax develops, start using it immediately using a transpiler, and have builds that target as ma…

Because it's not just syntax changes.

Re: Code that will break in Python 4

#85

Post by gh02t »

kazagistar wrote: post #12
gh02t wrote: post #9

Earlier quoted context omitted.

I believe they said they were going to try very hard to not do major backwards compatible breaking changes again. > 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…

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

He might have been just using that as a rough number for example purposes. Python does use semver loosely (effbot.org/pyfaq/how-does-the-python-version-numbering-schemae-work.htm).

I expect there probably will be at least some breaking changes in 4.0 or at least major new additions to warrant the major version bump, but I think they want to avoid anything that makes migrating code/libraries anything more than trivial for the majority of users. For 2->3 stuff like print as a function was straightforward, but other stuff like lazy range() or the Unicode strings would actually require people to make significant changes, which stagnated migration.

Re: Code that will break in Python 4

#87

Post by plorkyeran »

mikestew wrote: post #62
cwyers wrote: post #27

Earlier quoted context omitted.

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…

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 scheme really didn't matter very much to the users of the project as long as it wasn't completely incomprehensible.

Re: Code that will break in Python 4

#88

Post by s73v3r »

Grue3 wrote: post #30

There isn't all that much code written for Python 3 to care about backwards compatibility. IMO Python 4 should be: - backwards compatible with the latest release of Python 2 - contain all features of Python 3 in some form I think this will result in a very speedy adoption. In the future I propose the following numbering scheme: for any N > M, Python N contains all features of Python M and is backwards compatible with…

Or just update to Python 3. It's honestly not that hard.

Re: Code that will break in Python 4

#89

Post by renata »

ryandrake wrote: post #77
svisser wrote: 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.

This search turns up some quite a few results, including some OpenJDK code: https://searchcode.com/?q=if%28version%2Cstartswith%28%22win....

Re: Code that will break in Python 4

#90

Post by icebraining »

xyzzy4 wrote: post #55

Why don't they just stop changing the syntax? They already ruined print statements. Don't engineers have better things to do?

This has nothing to do with changing the syntax, it's a problem even if Python 4 has the exact same syntax and APIs as Python 3.
Post reply on HN