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

21–30 of 237 posts

Re: Code that will break in Python 4

#21

Post by incongruity »

bhaak wrote: post #15

Six is called the "Python 2 and 3 Compatibility Library" for a reason. I'm certain that when Python 4 will be released six will be updated so that six.PY3 will include Python 4. Of course, this opens the opportunity for two other compatibility libraries. "twelve" will be for supporting Python 3 and 4 and "twentyfour" will support Python 2, 3, and 4 at once (I hope nobody will seriously consider a library called "eigh…

The move from Python 6 to 7 will be the ultimate answer.

  import fortytwo

Re: Code that will break in Python 4

#22

Post by andrewingram »

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 many versions as you care to support.

Re: Code that will break in Python 4

#24

Post by wspeirs »

bhaak wrote: post #15

Six is called the "Python 2 and 3 Compatibility Library" for a reason. I'm certain that when Python 4 will be released six will be updated so that six.PY3 will include Python 4. Of course, this opens the opportunity for two other compatibility libraries. "twelve" will be for supporting Python 3 and 4 and "twentyfour" will support Python 2, 3, and 4 at once (I hope nobody will seriously consider a library called "eigh…

Unless Python 4 is 100% compatible with Python 3, I hope they wouldn't overload that constant!

Re: Code that will break in Python 4

#25

Post by frik »

Often I discover projects that are still in v2, and no words about v3 on their roadmap.

Maybe v4 should learn from JavaScript5 and Visual Basic 3-6.

Support v2 syntax out of the box using a (slow) shim layer if there is no

  "use strict"
in the first line. If that statement is present, don't load the shim layer and support only v4 syntax (faster).

That way old v2 code would still work without any changes.

Re: Code that will break in Python 4

#27

Post by cwyers »

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.

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 have reasonable disagreements with how SemVer works.

Re: Code that will break in Python 4

#28

Post by takluyver »

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.

There's code even in the stdlib which gets the major version by doing strversion[:3] , so it would see 3.10 as 3.1. That could be fixed, but who knows where else that assumption has been made.

Re: Code that will break in Python 4

#29

Post by knughit »

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 Python's philosophy is that the language designers known the one best way to do everything.

Re: Code that will break in Python 4

#30

Post by Grue3 »

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 Python M if and only if M divides N.

Post reply on HN