Seems like this is the fault of 'six' for defining PY3 in the first place.
[deleted]
Code that will break in Python 4
71–80 of 237 posts
Re: Code that will break in Python 4
#72Seems like this is the fault of 'six' for defining PY3 in the first place.
Indeed. You could just have a single method: "isV2()" (or whatever the "Pythonic" way to write that is--I've spent too much time in Java recently).
Re: Code that will break in Python 4
#73There 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…
This is just getting tiring. Please just switch to some other language so you and everyone else will be happy.
Re: Code that will break in Python 4
#74As 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…
Re: Code that will break in Python 4
#75> In this case, no code will get executed on Python 4 at all! Maybe `import six` should trigger ImportError when imported on python 4. Only "eight" or "twelve" should support Python4. :)
Surely it's `import twentyfour`? 2 x 3 = 6 => 2 x 3 x 4 = 24 ;)
I only imagined a need for spanning pairs of subsequent releases, but sure, why not?
Re: Code that will break in Python 4
#76Earlier 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.
This. Why would you gratuitously change the major version of a language, if there are no back-incompatible changes?
Everyone understands what 3.100 means, too.
Re: Code that will break in Python 4
#77Version 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.
Re: Code that will break in Python 4
#78Well 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, ...
Not 3.14, 3.141, 3.1416,.. ? It will become pithon.
No, that's TeX, see http://www.tex.ac.uk/FAQ-TeXfuture.html.
Re: Code that will break in Python 4
#79Earlier quoted context omitted.
... 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.
There's also code that's going to break `if sys.version_info[0] is not in (2, 3)`, as the article points out -- so bugs are going to need to be fixed either way.
Re: Code that will break in Python 4
#80No 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.
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.