> If there aren't backwards incompatible changes it will be called 3.10 not 4.0. Backwards Incompatibility is what changing the first number means.
That is what it means in SemVer, but SemVer is not a law. The author is the Director of the Python Software Foundation, so he's probably the second most qualified person in the world to comment on what the standards will be for 4.0 (the BDFL being the first).
He's essentially saying Python 3.x will be the last "major version" of Python as SemVer would describe it, but future bumps to the version number will be driven by decimalization rather than SemVer.
OTOH, while the current 2/3 split and maintenance of single source libraries may encourage "documented deprecation" as described in the article, that approach -- with no programmatic deprecation warnings and, consequently, never actually pruning the code of deprecated features, can't be a permanent state of affairs, if Python and its standard library are going to be maintainable in practice -- suggesting that it would be is essentially committing to unbounded accumulation of technical debt in the Python code base.
If PSF Python goes this way over the long term, I expect eventually a more nimble, decrufted fork will replace it for new development, with PSF Python relegated to legacy use.
To be fair, there's a long way to 2023 when 3.10/4.0 is expected to be released. The guy could be gone from the Python community for a number of reasons. Public opinion on numbering could have changed for a number of reasons. Backwards incompatible changes could be required for a number of reasons. Heck, it's even enough time for SemVer to be voted into law.
I dislike when people make promises about something set to happen a decade from then. Elected presidents can't keep their promises straight within half of that time and almost nobody remembers them. Promises which are aired on peak time TV to hundreds of millions of households. Who's gonna remember a blog post?
> OTOH, while the current 2/3 split and maintenance of single source libraries may encourage "documented deprecation" as described in the article, that approach -- with no programmatic deprecation warnings and, consequently, never actually pruning the code of deprecated features, can't be a permanent state of affairs, if Python and its standard library are going to be maintainable in practice -- suggesting that it would be is essentially committing to unbounded accumulation of technical debt in the Python code base.
I'm not sure where you are getting that idea from? PEP 387[0] does indeed recommend programmatic warnings through the `warnings` module and eventual removal of deprecated features.
> I'm not sure where you are getting that idea from?
From the article we are discussing (emphasis added):
---quote--
the widespread development of "single source" Python 2/3 libraries and frameworks strongly encourages the use of "documented deprecation" in Python 3, even when features are replaced with newer, preferred, alternatives. In these cases, a deprecation notice is placed in the documentation, suggesting the approach that is preferred for new code, but no programmatic deprecation warning is added. This allows existing code, including code supporting both Python 2 and Python 3, to be left unchanged (at the expense of new users potentially having slightly more to learn when tasked with maintaining existing code bases).
The author is a CPython core developer so I expect he has some idea what he is talking about. Nothing guarantees that CPython will stick to semantic versioning. There is precedent for that in the way the Linux kernel is doing version numbers now.
elegant?? It's 2014 and Guido is talking about event loops.
beautiful??? Atrocious more like.
Python is terribly put together (I'd say designed but it's clear no such process has taken place). It's a language that,
like PHP and to some extent Perl before it, rewards idiotic behavior, makes it extremely easy to end up with horrible
unmaintainable code and requires strict discipline and a lot of experience in order for it to "work" in anything that's not exploratory/throw-away in nature.
Of course the (mostly?) clueless masses love it, because they feel empowered. But really ask yourself, what has Python brought to the table in terms of paradigm shifts? It's no Lisp, Haskell or Ocaml.
Hell, even Java looks to be better, especially for beginner/mediocre programmers.
Good decisions are really irrelevant -- being a core developer (and, more importantly, Director of the PSF) means that Coghlan has considerable insight onto what kind of changes are likely to to be accepted in Python versions with particular version numbers, independent of whether those decisions are good or not.
They don't use semantic versioning. Python 2.0 was compatible with Python 1.5. (There was a licensing change, but that doesn't mean anything in semantic versioning)
> Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented. [Emphasis added]
I believe the intent of the sentence I've italicized is that while backwards incompatibility requires incrementing the major version, the converse is not necessary: a major version bump does not require backwards incompatibility.
Honestly, I feel bad for Python. It's a great all-purpose language, concise and powerful, if a little slow. I started tinkering with Flask over the weekend, and I wanted to do it in Python 3, but even the Flask site warns you that most Flask plugins are written only for Python 2. I last used Python at Hacker School, and also used Python 3. In the two years since, it doesn't feel like Py3k adoption has progressed at all. In the meantime, you'd be hard-pressed to find someone running PHP 4, and the PHP community has moved entirely away from it.
That warning is old. Most popular Flask extensions work well with Python 3 now. I've recently written a large Flask application targeted at Python 3 with no issues. If you have problems with Python 3 compatibility, report the issue, the maintainers are good about fixing these things.
Well, take the warning with a pinch of salt. Armin Ronacher (Flasks father) made HN first page a few times with rants about Python 3.
Not that he has no reason for whining, he is just a bit overdramatic regarding some Python 3 issues - but since English is not my first language this impression may be the language barrier kicking in.
No, he sounds melodramatic to me too. I just wonder why if these issues with Python 3 are so egregious, why haven't other framework developers chimed in with support?
Armin hates Python 3 and considers it a step backward. Ref this discussion: http://www.reddit.com/r/Python/comments/1ugg24/armin_ronache... /u/mitsuhiko is Armin. I'm not experienced enough with Python to pick a side, but for basic numerical analysis interfacing with Excel spreadsheets, Python 3 has worked fine. You don't seem to hear other prominent Python developers expressing these things (say, from Django) so he's unusually picky about Python handling of text/bytes.
I been using a couple Flask plugins and have yet to encounter one that doesn't support Python 3. If I do encounter one, I will most likely end up writing my own to fit my needs using their code as a guide.
Well, that's great! However, consider the fact that the message is still on the current docs (http://flask.pocoo.org/docs/0.10/advanced_foreword/#the-stat...), and that over the weekend, I decided to use python 2 instead of 3 because of this warning. I imagine that other Flask newcomers would be equally likely to shy away from Py3k if they saw this warning
Yeah, I think the warnings are old. I'm working on a pretty large Pyramid application with 30+ dependencies, all of which supported Py3 out of the box.
I like Python and I write a lot of Python, but I'm sad to read this article. I don't think Python is good enough to be mildly-frozen in a rapidly expanding and changing landscape of languages.
Py3k should have been a big change, big pain and serious gain, but was instead a small-ish change, big pain and little gain. After the suffering around Py3k, I wish the Python team would say "Py4k is going to be a big change because we're going to: clean up all inconsistencies, get rid of the GIL, focus on performance, etc". Py1-3k had a great 20 years; Py4+k should provide a further 20 years and I don't get that feeling from this article.
Fortunately, the maturation time for new languages has really shortened and fantastic, practical languages are becoming mainstream (go Rust!). I expect to be mostly off of Python in a few years...
I like Python, I use it daily, but in 10 years, it will be what Perl is today. If Rust had all the libraries that Python has today, I would have completely switched to Rust. So, we have Go and Rust growing rapidly and being well accepted and loved, so, not hard to imagine 10 years from now! I'm sure PyPy and other alternative implementations would be leading the parade at that time and possibly will take the language in a different direction adding incompatible feature to utilize best their specific platform and be competitive - similarly to what HHVM is to PHP. Life's moving at a faster pace now, every product has embraced the rapid release cycle, and Python seems too slow to evolve. Even Java, which was notorious for its slow pace, is quite different today! 10 years, really? Nobody has this patience! Life is too short anyway.
I find it sad that they won't make any changes to python that break backwards compatibility from now till 2023 or beyond. I mean, I'm all for maintaining backwards compatibility but if a language wants to evolve it has to be willing to make major changes, no language, especially one as featured as python, is at the point where they should stop making large changes and focus on perfecting and improving it. A language should never say its just going to "improve" from here on out. Its fine to have a stable stream that focuses on that but you need to be willing to take risks some times. At least that's my 2 cents, but what do I know.
(To clarify: I don't think a huge split should happen as it did previously from 2 to 3 but I do think that there should be a dev stream for implementing major new features)
Just to be clear, they aren't talking about disallowing changes that are backwards incompatible. For example, they could introduce a new 'foo' keyword that won't work on previous versions.
What they are saying is that they won't introduce changes that break the way already existing code works, like they did by changing the underlying behavior of existing types. I think this is a reasonable compromise that allows for software developers to get access to new features, while at the same time refactoring their code once migrated to a new runtime.
I disagree with the author. The whole point of changing the number is to indicate a major change. Its about making the language much better, and if doing that requires breaking compatibility, then so be it.
The idea is that there won't be large amounts of backwards incompatibility in a single version bump. We all know how well that worked out for Python 2 -> Python 3.
There will of course be backwards incompatible changes introduced through a normal deprecation cycle. No one is suggesting Python remain static forever.
Semantic versioning exists, means something, and is fairly unambiguous. It's not compulsory, but not following it is kind of a dick move.
At any rate, the point of the article was that Python 2 to Python 3 levels of disruption are not going to happen again and that people waiting for that (the "Python 4000" people) are going to be disappointed, so they should stop proposing disruptive and non-backwards compatible enhancements that aren't compelling.
Where he says "no major backwards compatibility breaks" is important.
edit: more succinctly, "don't worry, we won't pull a 2 to 3 level move again any time soon, if ever"
> The whole point of changing the number is to indicate a major change.
That may be what you'd prefer a major version number change to indicate, but the Director of the Python Software Foundation might have more insight than you into what the next major version number for Python will actually mean.
I haven't been keeping up with Python stuff lately and still use 2.7 for most stuff. Has Python solved the GIL problem yet? Or a threads still pretty useless?
I think it's incredibly naive to say that by 2023 there will be no need to evolve the language in a backward incompatible way, no need to clear cruft from ten years of continuous development, no need to incorporate new technologies like quantum CPUs or whatever they come up with.
History tells otherwise. I bet when they released Python 2 they were not expecting to break the APIs years ahead.
Making all strings Unicode seems to be what suck the PHP 6 effort years ago. Why is Unicode such a problem? Also, why does it have to be a core language feature? Why not just have a non unicode string type and a unicode string type?
Why not just have a non unicode string type and a unicode string type?
I think a better idea would be to have a string type that is encoding-agnostic (and internally might depend on compilation switches) but conceptually isomorphic to numbers in the range [0, 2^32) and a binary-data type which may have an encoding "annotation". And then the string type should be mostly not used, especially in the standard library. That way the cost of dealing with transformations among various encodings will be borne by those who care about those encodings, which isn't something that can be said of python3.
If one were developing a language from scratch, it would also be convenient that loads of legacy code doesn't assume the triviality of transformations between strings and binary data, or between different encodings of binary data. Obviously python3 couldn't rely on this convenience, but I wonder if we weren't making more trouble for ourselves by setting an expectation that str would be used all the time, and bytes only when absolutely necessary. I suspect the opposite custom would have been less troublesome.
In many cases, that's OK. Obviously I'm not talking about a database of customers and their addresses, etc. But having that sort of use case drive the evolution of a language seems like the tail wagging the dog.
I hope everyone learned that breaking compatibility for the sake of fixing syntax (amongst other things) just isn't worth it. I'm happy that Python seems to be finally pulling through this, but a lot of us are still stuck in 2.x land.
I really wish Python 3 had been about concurrency and making it a part of the core of the language. There are over a dozen different python concurrency packages out there and most of them are pretty different from each other. It's confusing as all get out, and we end up religious wars over which one to use.
Asyncio wasn't added until 3.4, so it was hardly the initial thrust of what Python 3k was trying to accomplish. Guido even admits he didn't even understand how Twisted's Deferred's worked until a year ago: https://groups.google.com/forum/#!topic/python-tulip/ut4vTG-...
... which I think is great that he really took the time and Pep 3156 is the better for it. I still feel like this should have been what Py3K was about though, and not tightening up semantics in the language. Who cares about the semantics? Python has warts but we love it anyway.
Agreed - I really enjoy writing Python but the more I use it the more I run into concurrency and performance bottlenecks. I think the big win will be moving away from the GIL but I image that to be a big ordeal.
If the core developers have committed to remaining C-ABI compatible with py3 until 2023 then there's basically no way anyone could fix the GIL. It would mean breaking ABI compatibility on the garbage collector and the interpreter. I find this aspect of the proposal kind of disturbing since it effectively prevents anyone from even trying to solve concurrency problems in mainline CPython for another decade.
GIL isn't so much a language issue as an implementation issue, and (as is the case with Ruby and MRI's GVL), I expect that the solution will be found in an alternative implementation (which may later become the mainline implementation), rather than an update to CPython.
In Python's case, my guess would be that PyPy will be the the implementation that makes this mainstream.
