Why Python 4.0 won’t be like Python 3.0

http://developerblog.redhat.com/2014/09/17/why-python-4-0-wont-be-like-python-3-0/

by Tsiolkovsky • 12 years ago

42 59 12 years ago

developerblog.redhat.com

njharman• 12 years ago

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.

ludamad• 12 years ago

Right, this confused me too. He mentions 4.0 will be 'more likely than 3.10', but never explains why.

ayrx5• 12 years ago

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.

shadowmint• 12 years ago

...because the cpython core developers have a history of making good decisions.

He may know what he's talking about, but being a core python developer certainly doesn't necessitate that in my books.

dragonwriter5• 12 years ago

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.

ayrx5• 12 years ago

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.

[0] http://legacy.python.org/dev/peps/pep-0387/#making-incompati...

scrollaway• 12 years ago

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?

1wd• 12 years ago

The BDFL also blessed[0] this blog post. (Not that this will stop the SemVer army.)

[0] https://twitter.com/gvanrossum/status/501172370690699265

chubot• 12 years ago

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)

ScottBurson• 12 years ago

From the Semantic Versioning 2.0 spec:

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.

gamesbrainiac• 12 years ago

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.

ayrx5• 12 years ago

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.

dragonwriter5• 12 years ago

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.

throwaway5752• 12 years ago

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"

dudus• 12 years ago

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.

latiera4• 12 years ago

It's 2014, Python still has a GIL, Guido thinks asynchronous event loops are hot stuff and you're talking about quantum CPUs?

programminggeek• 12 years ago

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?

ayrx5• 12 years ago

Why is Unicode such a problem? Also, why does it have to be a core language feature?

Because the vast majority of the world's languages cannot be handled solely using ASCII?

marcosdumay• 12 years ago

Why not just have a non unicode string type and a unicode string type?

That's exactly what Python did. It's also a problem, because it's a change in a core feature of the language.

VintageCool• 12 years ago

If any function anywhere in your code handles text in a way that is not Unicode safe, then your entire application is automatically not Unicode safe.

jessaustin2• 12 years ago

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.

jessaustin2• 12 years ago

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.

Igglyboo• 12 years ago

IMHO they have no other choice, the community has suffered enough from the 2/3 split as is. They don't want to risk fragmenting the user base again.

integricho• 12 years ago

What about the idea[0] (that Guido actually confirmed?) to use 1-based indexing?

[0] https://mail.python.org/pipermail/python-ideas/2011-Septembe...

fengb• 12 years ago

https://mail.python.org/pipermail/python-ideas/2011-Septembe...

privong• 12 years ago

It was all a joke: https://mail.python.org/pipermail/python-ideas/2011-Septembe...

Patrick_Devine2• 12 years ago

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.

dangoldin• 12 years ago

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.

freyrs3• 12 years ago

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.

dragonwriter5• 12 years ago

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.

m0th87• 12 years ago

Python 3 did address concurrency with the asyncio package. What it hasn't addressed is parallelism.

Patrick_Devine2• 12 years ago

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.

skizm• 12 years ago

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?

GFK_of_xmaspast2• 12 years ago

Nope! Still there!

latiera4• 12 years ago

Who needs threads when you get drumroll poor excuse of an asynchronous event loop!! In 2014 no less!

arenaninja3• 12 years ago

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.

davidism• 12 years ago

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.

mercnet• 12 years ago

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.

arenaninja3• 12 years ago

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

orf• 12 years ago

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.

alexanderss• 12 years ago

Just curious, you're a PHP developer?

arenaninja3• 12 years ago

Well I get paid to write mostly PHP, so I suppose I am. Personally, languages are tools, and it's rarely a disservice to learn more than one.

nether2• 12 years ago

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.

baq• 12 years ago

I'm happily coding Flask apps in Python 3.4 and haven't looked back.

scardine2• 12 years ago

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.

nether2• 12 years ago

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?

JacobEdelman• 12 years ago

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)

dmayle• 12 years ago

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.

frowaway001• 12 years ago

So Python is becoming the new C++ in terms of cruft?

"We can't change A, so let's add B which does A, but better" ... a version later ... "well, B didn't work out either, here is C".

CoffeeDregs• 12 years ago

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...

latiera4• 12 years ago

You should be off Python already, no need to wait for Rust.

Ocaml, F#, Common Lisp, Scala/Clojure (if JVM) are languages that blow Python out of the water for anything that's not scripting/throw-away code.

kolev• 12 years ago

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.

GFK_of_xmaspast2• 12 years ago

"It’s also worth noting that Python 3 wasn’t expected to be as disruptive as it turned out to be. "

I really have to wonder how in-touch the python high command is with the community as a whole.

Why Python 4.0 won’t be like Python 3.0

Related Stories