I'm totally incapable of detecting whether this is satire. Is this satire? It should be.
Code that will break in Python 4
171–180 of 237 posts
Re: Code that will break in Python 4
#172Guido has stated to not compare semver in the past.[0] Will there be a 3.10 or go to 4.0 after 3.9, per one of his core developers?[1] It's hard to tell with Python's leadership (no intentional mockery of the term leadership). My guess is that they'll indeed push onwards to Python4 as soon as possible. This being another attempt to make Python2 look as old and crufty as possible. "You're still on Python2? Wow, I'm on…
Amen!
Ruby managed the transition to unicode much better as they delivered 2x performance increase at the same time AND labeled the new version 1.9 instead of two. Much the same problem.
Yes python 2 is OK but it's legacy mode and people will move on. I think one of the selling points of python vs ruby is that its so often OK to just use system python(2) versus ruby where you really need to use something like rbenv. Selling point for ruby is that the community is absolutely obsessed with making good tools to facilitate working with it.
I have already in my mind decided the future is in languages that are designed with parallelism in mind. Another breaking change for that?
Re: Code that will break in Python 4
#173Earlier quoted context omitted.
This search turns up some quite a few results, including some OpenJDK code: https://searchcode.com/?q=if%28version%2Cstartswith%28%22win... .
that's irrelevant because Microsoft fakes version information for applications by default[1]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
It's cute, because the dedication to backwards compatibility is so uniquely Microsoftian: "We're going to create this API that idiots will inevitably abuse or misuse. Then, in the next version, after all the idiots have abused or misused the API, we're going to deliberately return wrong results from it so that the idiots' applications don't all break." It's really baked into their DNA, all the way back to the early days of Windows where they replicated all those DOS bugs so buggy games that took advantage of them would still function on Windows.
Re: Code that will break in Python 4
#174Earlier quoted context omitted.
Those two statements are mutually incompatible. Python3 is a different language with different semantics. It is possible to work in a subset of python2 and python3 that is syntactically valid under both interpreters but this is not what you are suggesting.
No, you are confusing "features" and "syntax". Both Python 2 and Python 3 are Turing complete. They have the same expressiveness. It's possible to backwards-compatibly extend Python 2 to achieve feature-parity with Python 3 while preserving Python 2 syntax. Python 4 proposed by me is possible, while Python 6 (which must be backwards-compatible with both 2 and 3) is probably not possible.
> It's possible to backwards-compatibly extend Python 2 to achieve feature-parity with Python 3 while preserving Python 2 syntax.
The syntax between 2 and 3 is essentially the same. A few minor tweaks here and there, but nothing major. Your point is a bit pointless because changes to the language that are not on the syntactical level (i.e unicode/bytes) cause the meaning of the code to change, despite the syntax being the same.
Re: Code that will break in Python 4
#175Earlier quoted context omitted.
> 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.
Please elaborate. Which feature of Python 3 would be impossible to implement in Python 2? Note that Python 3 code is not guaranteed to work in Python 4, but you are guaranteed to (relatively) painlessly port it, since all Python 3 features are implemented in Python 4 in some way.
Python is Turing Complete, so everything you can do in Py3 you can do in Py2, but so you can also implement in Brainfuck.
The question is whether programming in one version vs the other is more enjoyable.
Re: Code that will break in Python 4
#176This post and thread are a trainwreck.
Re: Code that will break in Python 4
#177Earlier 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.
> thats stupid
Please don't. From the site guidelines: When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Re: Code that will break in Python 4
#178How come the title was changed?
Re: Code that will break in Python 4
#179Earlier quoted context omitted.
Are you expecting the same running interpreter to have both python 2 and 3 modules at the same time, with calls between the modules working? You can easily keep things separate - python 2 executable is named python while python 3 is python3. https://www.python.org/dev/peps/pep-0397/ Sadly concurrent running in the same interpreter won't work because Python 3 has different types for strings (unicode only) and a bytes…
Actually C++ is not a superset of C. And it does have these kinds of issues. C++ continued to diverge with C99/C11. https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B Function pointers are one scary area. I don't know if C++11/C++14 decided to fix this yet. Most people relied on undefined behavior to make this work.
Since we are in pedant's corner, note that I very carefully used past tense. Yes it originally was a design goal.
Source: The Design and Evolution of C++, by Bjarne Stroustrup. (I don't know which printing I have.) Page 120, Section 4.5 "No gratuitous incompatibilities with C". It explains my original claim, and also why it couldn't be 100% compatible due to some other C++ desirables (eg better type safety). Partial quote:
"C++ doesn't aim at 100% compatibility with C because that would have compromised the aims of type safety and support for design. However, where these aims are not interfered with incompatibilities are avoided - even at the cost of inelegance. In most cases, C incompatibilities have been accepted only when a C rule left a gaping hole in the type system."
Re: Code that will break in Python 4
#180Python 2 going away in 2020? Yeah right. Python 3 is a dead end. If they rebooted Python 4 to run Python 2, maybe Python 4 would be relevant. As it stands, Python 3 is a total disaster and will never replace 2. Trying to improve unicode handling? Check. Replacing the print statement syntax just because? Ohmygodstupid.