Live data from Hacker News

Code that will break in Python 4

astrofrog.github.io

31–40 of 237 posts

Re: Code that will break in Python 4

#31
post #24
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!

Still wouldn't matter unless you allow for pure evil like 'import twelve as six' EDIT: wouldn't matter because "six" shouldn't allow itself to be imported on PY4.

Re: Code that will break in Python 4

#33
post #24
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!

Yes, they should make the constant True for both Python 3 and Python 4. If you need to make a finer distinction, use a different package.

Re: Code that will break in Python 4

#35
post #25

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.

The syntax changes introduced in python 3 are easy to fix, and most of them are backwards compatible with python 2.7.

The whole string/byte dichotomy, however, is a major change that I don't think any shim layer could handle correctly without major bugs, short of defining a whole new string-like class.

Re: Code that will break in Python 4

#36

No problem! I've already fixed it so that all my code is forward compatible with Python 7000, despite not knowing what any of the syntax or library changes are going to look like.

There is a difference between writing code that might break and code that is guaranteed to break. Badly written version checks are guaranteed to break.

Re: Code that will break in Python 4

#38

Holy shit - people actually write code like this?

See previous HN discussion about YouTube's browser-version sniffing breaking video playback on Firefox because the sniffer was checking for version 43 and version 44 was released...

https://news.ycombinator.com/item?id=10877810

Post reply on HN