
Why Python 4.0 won’t be like Python 3.0 - Tsiolkovsky
http://developerblog.redhat.com/2014/09/17/why-python-4-0-wont-be-like-python-3-0/
======
njharman
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.

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

~~~
ayrx
> 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...](http://legacy.python.org/dev/peps/pep-0387/#making-incompatible-
changes)

~~~
dragonwriter
> 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).

\---end of quote---

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

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

~~~
nether
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?

~~~
scardine
I guess Ronacher is truly, deeply passionate about Python while the core
developers are more on the practical side.

This is one of the reasons why I like his code, I find all his projects
inspiring.

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

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

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

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

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

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

------
skizm
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?

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

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

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

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

[0]: [https://mail.python.org/pipermail/python-
ideas/2011-Septembe...](https://mail.python.org/pipermail/python-
ideas/2011-September/011448.html)

~~~
privong
It was all a joke: [https://mail.python.org/pipermail/python-
ideas/2011-Septembe...](https://mail.python.org/pipermail/python-
ideas/2011-September/011462.html)

------
programminggeek
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?

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

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

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

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

