Why even adapt for python 3? Nobody uses that stalinist version of python anyway. Its incredibly bad to have to use ifdefs in a scripting language like that. Code should be written so that it works regardless of version.
Code that will break in Python 4
101–110 of 237 posts
Re: Code that will break in Python 4
#102They could always take the Microsoft route: Python 4 will be internally versioned as Python 3.1 to avoid this sort of problem.
"Version: Python 3.1 (Python 4.2)"
Re: Code that will break in Python 4
#103Six 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!
If it was 100% compatible it wouldn't be Python 4, it'd be Python 3.x.x.
Re: Code that will break in Python 4
#104Earlier quoted context omitted.
Unless Python 4 is 100% compatible with Python 3, I hope they wouldn't overload that constant!
If it was 100% compatible it wouldn't be Python 4, it'd be Python 3.x.x.
Someone recently made the argument to me that semantic version has nothing to say about increasing the major version even though there are no backwards compatible breaking changes. I am not sure what the point of increasing the major version would be in this case, and I think it's a bad idea, but I guess that person was correct in the literal sense of how semver is defined.
Re: Code that will break in Python 4
#105As 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…
You know Python 3 is not backward compatible with Python 2, right?
Whether that was a smart decision is another discussion. But to call them both Python 2 would be moronic.
Re: Code that will break in Python 4
#106Is 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.
Same with Babel in JavaScript-land, there's a runtime module for changes that can't be achieved with a syntax transform alone.
Re: Code that will break in Python 4
#107Earlier quoted context omitted.
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.
The shim layer would have to convert all strings from v2 representation every time to the v4 implementation. Slower, but at least v2 could run unchanged. As we all know certain code won't be touched for whatever reason. It could certainly prevent some from deciding to move off to other languages like Go, Elixir, Node.
Your shim layer would have to make assumptions on the encoding of your strings, which can lead to nasty bugs.
And also handle reading from files correctly, or list file names from the os, or anything that communicates outside of the python interpreter.
The main reason why python 3 was created was to manage these complexities, and even then some people[1] say it wasn't done properly.
[1] http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
Re: Code that will break in Python 4
#108The whole Python versioning fiasco is simply baffling to me as an outsider. Why not mark Python 3 modules with a tag, or different file extension, or anything, and require the Python 3 interpreter to be able to interpret Python 2 code as well as Python 3 code?
This is e.g. how the (roughly analogous) split between C and C++ is handled, and it works fine for the most part. No bizarre polyglot code games.
Edit: Just to be clear, C++ is not a superset of C: http://stackoverflow.com/a/1201840/270610
Re: Code that will break in Python 4
#109The idea of using a runtime conditional to target different major versions of a programming language is hilarious. Really, given the Python 3 embarrassment, I'm not confident in the language as a long-term option.
Re: Code that will break in Python 4
#110Why even adapt for python 3? Nobody uses that stalinist version of python anyway. Its incredibly bad to have to use ifdefs in a scripting language like that. Code should be written so that it works regardless of version.
I'm not entirely sure if this is sarcasm...