
Code that will break in Python 4 - astrofrog
http://astrofrog.github.io/blog/2016/01/12/stop-writing-python-4-incompatible-code/
======
colanderman
The 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](http://stackoverflow.com/a/1201840/270610)

~~~
rogerbinns
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/](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 type, while Python
2 has a str type (pretty much like bytes but can also be treated as a string)
and a separate unicode type. Python 2 had code that tried to do the right
thing automagically with str, such as automatic promotion to unicode where it
looks like you really meant a string and that is what is needed. Automatic
promotion can fail, be unexpected, is hard to test and numerous other issues.
That is why Python 3 was needed and why it needed to be incompatible. To have
Python 2 and 3 code interoperate in the same interpreter would require another
layer of automatic promotion/demotion and heuristics when data goes between
the two.

C++ was explicitly defined to be a superset of C so it doesn't have these kind
of issues. The analogous situation would be if C didn't distinguish between
long and pointer types, and C++ did. You'd need rules for how to convert
between the two worlds, trying to combine or disambiguate the types depending
on which way types are going. It would be a mess.

~~~
colanderman
Yes, that is what I expect. The various flavors of C and C++ get along just
fine that way.

C++ is not a superset of C:
[http://stackoverflow.com/a/1201840/270610](http://stackoverflow.com/a/1201840/270610)

C and C++ have a similar issue with strings. C code uses NUL-terminated char
arrays, while C++ generally uses std::string. If you want to interface the
two, you need glue code (written in C++).

Surely Python 3 can work the same way: to share strings between a Python 2 and
Python 3 module, you need to convert them using glue code written in Python 3.
Sure it's messy, but writing polyglot code is messier.

~~~
hyperpape
I wonder if there's even a reasonable way to do this in Python. In C, strings
are data that you're explicitly passing around, but in Python, you are
constantly calling __getattribute__ under the hood just to execute your code.

I don't know that it would be impossible to make that all work, but I wouldn't
assume that it is.

~~~
comex
You don't _need_ to actually convert anything: Python 2's str can be
identified with Python 3's bytes, and unicode with str. You 'just' need to
have their __getattribute__ methods, along with a ton of standard library
functions, check the Python version of the caller and change behavior
accordingly. Ugly, but I think it would mostly 'just work' for user code.

------
mpdehaan2
No problem! I've already fixed it so that all my code is forward compatible
with Python 7000, despite not knowing what any of the syntax or library
changes are going to look like.

~~~
btilly
There is a difference between writing code that might break and code that is
guaranteed to break. Badly written version checks are guaranteed to break.

~~~
dietrichepp
Which is why GetVersionEx() on Windows will always tell you that you are
running Windows 8, unless your application has a manifest entry indicating
specifically that it is compatible with a higher version.

Microsoft thought there were too many broken version checks in the wild, so
decided to hobble the version check function as a fix. I can understand why
they did it.

~~~
Pxtl
Hell, the reason Windows 10 is Windows 10 is because of all the bad version
checks looking for "9X"

~~~
sanderjd
Ha! Is that true in a documented fashion or just widely suspected? I had never
heard that, but it makes perfect sense.

~~~
netmare
That's just a silly rumor. The only examples I've seen of programs using
strings to do version checks are Java ones. The function that returns "Windows
95" for Win4.0.xx could simply have been made to return "Windows Nine" or
"Windows\xa09" for Win6.4.xx. "Problem" solved. The rest of the world, who's
been using GetVersionEx(), wouldn't even notice it.

IMHO, the most probable reason was marketing (OS X).

~~~
dietrichepp
No, it's not a silly rumor. It _was_ Java programs (among others), but
Microsoft takes backwards compatibility very seriously. Windows 9 builds were
tested internally at Microsoft, and the bugs in third-party programs drove the
decision to bump the version to 10.

~~~
Dylan16807
Java would have returned "Windows NT (unknown)" as far as I know. How would
programs get a string that said "Windows 9"? What API would be involved? What
would they be reading that is text-based, wouldn't lie, [and existed on 9x]?

------
bhaak
Six 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 "eight").

~~~
wspeirs
Unless Python 4 is 100% compatible with Python 3, I hope they wouldn't
overload that constant!

~~~
ChristianBundy
If it was 100% compatible it wouldn't be Python 4, it'd be Python 3.x.x.

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

------
btilly
I am reminded of the horrible hacks that got encoded in various http user-
agent strings so that new versions of browsers would be identified as various
other older browsers so that badly written sites would send them the right
version of the site for the features that they supported.

------
jobu
As someone that uses Python intermittently it seems like there's still a lot
more tutorials, Q&A, and documentation for v2 on the internet than for v3.
When searching for info about python it's often difficult to tell if I'm
looking at something for v2 or v3, and when I can tell it's usually for v2.

~~~
gipp
Usually when it's hard to tell that's because it applies to both. The
differences between the two are really not that large.

~~~
vegabook
...which begs the question: why are there any differences at all!

~~~
Latty
Because the differences were important and central to the language.

~~~
rjurney
print "HI" # oh my god, the horror!

print("HI") # yaaaah, order out of chaos

Unconvincing.

~~~
azernik
That is not the central and essential change. It's just a style cleanup that
they did while they were breaking compatibility anyway.

The big change was string/byte-array typing, which was a mess in Python 2 and
was cleaned up in Python 3. That's one of those things that, when changed,
inherently breaks old code in ways that, like wizards, are subtle and quick to
anger.

Also changing lots of sequence functions like range() to return iterators
instead of lists, but those are mostly pure performance wins that don't break
compatibility except for some very specific use cases.

~~~
orangecat
_The big change was string /byte-array typing, which was a mess in Python 2
and was cleaned up in Python 3._

And made worse in some cases (e.g.
[http://legacy.python.org/dev/peps/pep-0461/](http://legacy.python.org/dev/peps/pep-0461/)).
Even aside from that, I would argue that the benefits of cleaning up Unicode
didn't come close to the cost of breaking everyone's code and fragmenting the
language for 7+ years.

------
wyldfire
> In this case, no code will get executed on Python 4 at all!

Maybe `import six` should trigger ImportError when imported on python 4. Only
"eight" or "twelve" should support Python4. :)

~~~
scotchmi_st
Surely it's `import twentyfour`?

2 x 3 = 6 => 2 x 3 x 4 = 24

;)

~~~
rjeli
LCM(2,3,4) = 12

~~~
zem
LCM would imply that anything supporting python4 would also support python2,
which is clearly not the case!

------
to3m
2020! I wonder if I'll have more luck finding the time to upgrade my python 2
scripts in the next four years than I've had in the last four?

~~~
vegabook
much more likely: you'll finally find the motivation to upgrade your code, not
to Python 3 which is 5% better than 2 and 50% more of a pain-in-the-butt, but
because there are a multitude of new, faster, parallel-aware languages that
are orders of magnitude better, and already make 3.x look like a dinosaur.
Move from one dinosaur to a marginally better-but-fussier dinosaur? Doubt it.

~~~
andybak
> new, faster, parallel-aware languages

There were faster languages (and probably more 'parallel-aware' languages -
it's not an area I'm very knowledgeable about) before Python but that wasn't
the reason it took off. It's fairly unlikely to be the reason it dies off
either.

Python remains one of the most humane languages out there and that's a quality
that is much more intangible and hard to replicate.

~~~
Nrpf
What do you think about Julia?

~~~
andybak
I don't do much (any) numerical stuff so I don't have a terribly informed
opinion.

Glancing at the code samples, I don't hate it. It looks rather pleasant.

I can't fathom

~~~
Nrpf
Its also for general programming.

------
incepted
> We don't really know yet what Python 4 will look like, but we can be pretty
> sure that the transition from Python 3 to Python 4 will be a lot smoother

Doesn't compute.

You can't say you don't know anything about Python4 and immediately follow up
with suggestions on how to program for it.

And if you really want to be consistent, at least:

    
    
        if (python2):
          // python 2
        else if (python3):
          // python 3
        else:
          raise "I have no idea what I'm doing"
    

At any rate, given the time lapse between Python releases and how catastrophic
version migrations have been so far, it's safe to say that by the time Python
4 comes out (if ever), we will all have long retired from development.

~~~
x1798DE
My understanding is that the consensus is that Python 3 was the last time
backwards incompatible changes would be made to the language. The author's
point is that this makes Python 2 a special case, so you should make the
default behaviour the Python 3 behaviour.

------
markrages
Seems like this is the fault of 'six' for defining PY3 in the first place.

~~~
hyperpape
Indeed. You could just have a single method: "isV2()" (or whatever the
"Pythonic" way to write that is--I've spent too much time in Java recently).

~~~
k33n
Needs more subdirectories.

------
twblalock
The history of Python 2, 3, and 4 is a great lesson in how _not_ to manage
changes and versioning in a language.

~~~
andybak
Give a specific example of something that should have been done differently.
It's hard to know which angle you're coming from with a throwaway comment like
this.

~~~
sitkack
From Brett Cannon [http://www.snarky.ca/why-
python-3-exists](http://www.snarky.ca/why-python-3-exists)

I think maybe the Python 2/3 split was a huge performance piece on how NOT to
evolve a language, but we just copied Perl 6.

Do you think a stop the world, forced upgrade is something that should be done
in the future? Was it avoidable?

------
kasbah
Reminds me of when Linus tagged Linux 3.0 and it broke a bunch of peoples code
due to their bad version checks. Linux 2.x had been going for about 15 years.

~~~
mioelnir
When FreeBSD 9 was released, and the development tree thus became FreeBSD 10,
a lot of applications broke. GNU autotools considered a FreeBSD version number
starting with 1 as FreeBSD 1.

Historical note: FreeBSD1 was rebased after the AT&T lawsuit on top of the
unencumbered Berkeley release as FreeBSD2. To run FreeBSD1, you probably still
need an AT&T UNIX license.

~~~
phyzome
This is apparently also one reason Windows jumped from 8 to 10 -- "Windows 9"
would have been read as "Windows 98" (or 95) by some software. :-(

------
bitwize
They could always take the Microsoft route: Python 4 will be internally
versioned as Python 3.1 to avoid this sort of problem.

~~~
StavrosK
"Version: Python 3.1 (Python 4.2)"

~~~
JBiserkov
"Version: Python 3.1 (Python 4.2) ruby 2.1.6p336 (2015-04-13 revision 50298)
[x64-mingw32], like 2.7.8 [GCC 4.8.3] on cygwin"

------
brrt
I'm totally incapable of detecting whether this is satire. Is this satire? It
should be.

------
wmil
I was listening to a developer podcast and one of the hosts (Jeff Roberts?)
had the right idea about version checks...

Never allow developers to read the version number. Instead have a function
where they pass in the version number and get a boolean about whether or not
it's supported.

It's really the only way to avoid code problems like this.

------
svisser
Version checks are also the reason why we have Windows 10 and not Windows 9
because people checked whether the OS version started with "Windows 9" (for
Windows 95 and Windows 98).

~~~
ryandrake
The source to that information (as far as I can tell) is a Reddit post
claiming to be from a Microsoft developer. I've worked with programmers dumb
enough to write such a version check, so I totally believe this might be true,
but I'd love an official source.

~~~
renata
This search turns up some quite a few results, including some OpenJDK code:
[https://searchcode.com/?q=if%28version%2Cstartswith%28%22win...](https://searchcode.com/?q=if%28version%2Cstartswith%28%22windows+9%22%29).

~~~
gruez
that's irrelevant because Microsoft fakes version information for applications
by default[1].

[1] [https://msdn.microsoft.com/en-
us/library/windows/desktop/ms7...](https://msdn.microsoft.com/en-
us/library/windows/desktop/ms724439%28v=vs.85%29.aspx)

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

------
zanny
As 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 for years.

I just wish software would take versions seriously. Please. For my sanity.

~~~
untog
Semantic versioning _is_ taking versions seriously. Far more seriously than
arbitrary version numbering does, anyway.

Don't get me wrong, I do understand your frustration. But "previous increments
actually meant something, so when it now no longer does" is just totally
incorrect. Previous increments were an attempt at bundling together a series
of unrelated changes into a 'thing'. What that 'thing' is varied wildly
between organizations and products. Semantic version increments are breaking
changes, pure and simple.

~~~
zanny
Neither Linux or Python (if 4.0 is non-breaking) are following semver.

For Linux, 2.0 was just SMP support. In defense of Linux, there has never been
a backwards breaking major version increment, suits are just paranoid about
the number going up randomly. They _want_ it to have meaning, even when it
does not.

For Python, 2.0 was _not_ breaking, but 3.0 _was_. Now that major version has
breaking significance in accordance with semver, business interests _will_
treat it like that and make a big deal out of a 4.0, even if it is not
breaking. I know this because I deal with clients paranoid about Linux 4.0
_all the time_ , despite insistence Linux never breaks backwards
compatibility.

Fundamentally neither project is adhering to semver and _are_ using arbitrary
version systems, but if you are going to do that, it would be so much nicer if
they would use a two number version - major-patch - rather than having a dead
major version that is meaningless. Honestly, in programming languages, Python
3 should have legitimately been a language fork like C++ is to C rather than a
version increment (like Obj C is to C) - programming languages are making a
bad habit of making breaking changes in a language, and while its
understandable that the developers no longer want to maintain the old
standard, its deceptive to call the version increment the same language since
the semantics change when you make major breaking changes like that.

------
JupiterMoon
This is a surprisingly common anti-pattern. See also potential reason why
there was no Windows 9 (programs checking for Windows 95/98) and various
breakages for commercial programs on Linux when they check the kernel version.

~~~
rplnt
Slightly related is Opera transitioning from version 9.x to 10.x:
[http://www.sitepoint.com/opera-10-user-
agent/](http://www.sitepoint.com/opera-10-user-agent/) (couldn't find the
original dev blog)

------
ctz
Has there actually been a statement that python 4 will be backwards compatible
to python 3?

~~~
gh02t
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 expect the stable Application Binary Interface (as first defined in PEP
> 384) to be preserved across the boundary.

[http://www.curiousefficiency.org/posts/2014/08/python-4000.h...](http://www.curiousefficiency.org/posts/2014/08/python-4000.html)
(which was linked by Guido from his Twitter).

~~~
kazagistar
... thats stupid. Semver isn't that complicated, and everyone understands what
3.10 means.

~~~
cwyers
Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very
helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991.
Not having precognition made it difficult for Python to adopt SemVer, and now
that they have versioning practices in place there needs to be more than "I
like SemVer" as a compelling argument for them to change. Especially since
there are reasonable people who have reasonable disagreements with how SemVer
works.

~~~
mikestew
I have nothing to back this up other than my increasingly unreliable memory,
but the semantics of SemVer goes back further than 2009. Maybe it wasn't
formally written out, but as far back as the 90s that XX.YY.zz could be
translated as XX == major changes, breaking changes for APIs, reworked UI for
end-user apps. YY == some new functionality, no breaking/major changes. zz ==
bug fixes.

It probably goes back further than that, and it was probably one of those
"everybody knows..." kind of things, but it definitely didn't start to be a
widely-known definition a measly seven years ago.

~~~
plorkyeran
There were a lot of projects informally using what semver defined, but there
were also a lot of other popular versioning schemes. Odd minor = unstable
version, even minor = stable version used to be pretty popular and is still
used by a few projects.

The main thing that helped make SemVer the default assumption was package
managers that baked it into the dependency resolution, as until then a
project's versioning scheme really didn't matter very much to the users of the
project as long as it wasn't completely incomprehensible.

~~~
jrochkind1
Well, baking it into dependency resolution is a response to the fact that
figuring out if there were breaking changes in any given update becomes
intractable as your dependency tree/graph gets large (and multi-levelled),
when each dependency uses it's own versioning scheme, no matter how
comprehensible they are individually.

------
chubot
Well Python doesn't use semantic versioning, but if it did, there would
probably be no Python 4.0. It will just be Python 3.15, 3.16, ..., 3.99,
3.100, ...

~~~
manojlds
Not 3.14, 3.141, 3.1416,.. ?

It will become pithon.

~~~
Tenobrus
No, that's TeX, see [http://www.tex.ac.uk/FAQ-
TeXfuture.html](http://www.tex.ac.uk/FAQ-TeXfuture.html).

------
jug
> My current expectation is that Python 4.0 will merely be "the release that
> comes after Python 3.9". That's it.

What? If that's the idea, don't be stupid and just call it Python 3.10 then.

Otherwise, won't we risk a completely unnecessary major versioning problem as
outlined in this very article??

Sometimes it feels like the Python team wants to change the major version
number only to teach the development community a lesson about coding libraries
right, not because they have to. This kind of masochistic idea of deciding
version numbers, if it's there, needs to go since this lesson will never be
learnt by each and everyone due to the immense size of the community. And if
there is a support issue in some libraries, the ripple effect can and will
affect other projects as well.

------
artursapek
Holy shit - people actually write code like this?

~~~
fixermark
See previous HN discussion about YouTube's browser-version sniffing breaking
video playback on Firefox because the sniffer was checking for version 43 and
version 44 was released...

[https://news.ycombinator.com/item?id=10877810](https://news.ycombinator.com/item?id=10877810)

------
dawnbreez
We don't even write code that doesn't break on Py3.

------
plainOldText
Hopefully this won't be huge problem in Python 7, as all python scripts will
be just two lines of code:

    
    
        import ai
        ai.run('This script <describe in natural language what you'd like this script to do>.')

------
PythonicAlpha
This should be normal routine -- it is called "defensive programming".

------
cben
Real life example of similar bug:
[https://github.com/firebase/firepad/issues/167#issuecomment-...](https://github.com/firebase/firepad/issues/167#issuecomment-100405275)
=>
[https://github.com/firebase/firepad/commit/e732e6124c56ac056...](https://github.com/firebase/firepad/commit/e732e6124c56ac0568d249c042c36a435303f7f6)

------
andrewingram
Is 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 many versions as you care to support.

~~~
s73v3r
Because it's not just syntax changes.

~~~
andrewingram
Same with Babel in JavaScript-land, there's a runtime module for changes that
can't be achieved with a syntax transform alone.

------
cianuro
I feel like I'm taking crazy pills

------
tempodox
Python 4, really? I wonder how that will work out. Currently, we have to
maintain at least 2 incompatible Python ecosystems on a box. With Python 4 it
will be at least 3 to maintain if nothing changes. That's not something I'm
looking forward to.

------
reality_czech
It's ok. I'm sure that the Python development team will manage the version
transition in a sane and responsible... heh... hehe... HAHAHAHAHAHAHA.

Sorry, I couldn't keep a straight face for that one.

------
OrangeTux
I don't get it. When Py4 comes in sight they'll fix it probably so `six.PY3`
is only True when using a Python3 interpreter and I guess they'll introduce a
viariable `six.PY4`.

~~~
ergothus
That's the point...if the code says "If Py3, do (modern code) else do (old
code)", then when/if py4 comes out, and six.PY3 is False, you end up running
(old code).

Obviously you don't know if (modern code) is Py4 compatible, since we don't
know what py4 is, but while the py3 code MIGHT be runnable under py4, the py2
code is ALMOST CERTAINLY not going to run under py4.

So instead, make the check for PY2 code:

If Py2 do (old code), else do (modern code).

That MIGHT break under Py4, if modern code isn't future code, but also MIGHT
work, whereas the other version WOULD break under Py4.

Same story if you're using sys.version[] rather than six.

------
geocar
This reminds me of something else[1]

[1]: [https://cr.yp.to/y2k.html](https://cr.yp.to/y2k.html)

------
BuckRogers
Guido 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 4!". That's the type of political and
psychological game the Python core dev team has been playing since 2008 with
3's release. Right alongside the 2020 EOL, another political move. Even though
Python 2.7.'10' was never supposed to exist but they went back on that.

This because Python3 is mere technical churn, it is not true technical
innovation.

The issue here is really one with the Python core development team. They have
also adopted every niche feature into Python3 by whoever came along to ask for
it.[2] This was done for the same reasons as the relative rush to rebrand the
failed 3.x branch as 4. An attempt to stir up any hype possible for 3.0+.

They got so much wrong with Python3. Feature soup, unicode, and performance
losses over 2. Unicode-by-default is the big deal and they didn't even get
that right. They simply remapped unicode to str. Which for such a big breaking
change, should've been UTF8 alongside other new languages such as Go.[3] But
it's worse than that, Python3's feature soup continues in 3.6 there will
likely be a 4th string formatting option[4] among throwing everything they can
against the wall to see what sticks (while bloating the supposedly simple,
"beginners" language).

While Python2 has been riding high in popularity[5], it has absolutely nothing
to do with Python3. It's in spite of it.

There's good reason the core dev team "extended support" for 2.7. It's because
they really did create a new, much less successful language and would've lost
complete control of Python had they not done it.

Python3 is a language that looks mostly like Python, but is Python in name-
only. Worse of all, it doesn't stand on it's own two feet with technical
merits. I would personally recommend sticking with 2 until 3 ever makes sense,
or finding something else to use like Swift or Go.

Unlike a web browser or another piece of software, the "latest version" of a
programming language is not always in the end-user's best interests.

[0][https://twitter.com/gvanrossum/status/583346987925278720](https://twitter.com/gvanrossum/status/583346987925278720)

[1][http://www.curiousefficiency.org/posts/2014/08/python-4000.h...](http://www.curiousefficiency.org/posts/2014/08/python-4000.html)

[2][http://learning-python.com/books/python-
changes-2014-plus.ht...](http://learning-python.com/books/python-
changes-2014-plus.html#coroutines35)

[3][http://lucumr.pocoo.org/2014/5/12/everything-about-
unicode/](http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/)

[4][https://www.python.org/dev/peps/pep-0498/](https://www.python.org/dev/peps/pep-0498/)

[5][http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

~~~
orf
Damn, I upvoted you way too early.

> They have also adopted every niche feature into Python3 by whoever came
> along to ask for it.

You link to async/await as an example? You realize that's a _huge_ deal and is
an awesome feature right? It was something sorely missing, but replicated well
with generators (thanks to Python being awesome) since Twisted and Python 2.4.
Now is exactly the time to ratify it into the language. His complaints about
concurrent programming are senseless as async/await are single threaded and
avoid most of the concurrency issues you would typically run into when using
threads. They also look a hell of a lot nicer and explicit than 'yield from
x'.

That whole link[1] is garbage, I don't have enough space to comment on the
many absurd statements it contains, but FYI the scientific community in Python
is _huge_ and they have been begging for a matrix operator.

You sound like you have a large Python 2 codebase that you don't have the time
or resources to upgrade. That sucks. Don't channel that hate into Python 3
though. Start your new projects in it and have a play, you will like it.

1\. [http://learning-python.com/books/python-
changes-2014-plus.ht...](http://learning-python.com/books/python-
changes-2014-plus.html#coroutines35)

Edit: That link is like reading the republican far-right news about how Obama
is a Muslim sleeper agent. One of his complaints is that "The docs are broken
on Windows and incomplete" when he's viewing them using an IE6 frame inside a
Windows help file - it even tells him his browser is 'ancient', and he still
complains some non-important JS is broken? Oh god. Or how getting rid of .pyo
files is a terrible thing, or how type annotations will eventually destroy all
that is holy about dynamic typing....

~~~
BuckRogers
No, I don't have any significant Python2 codebase. I'm making my own judgement
calls off the situation and facts as I see them. I wouldn't build any project
in Python3 today, because the prod-ready PyPy option isn't there which adds
CPU performance as a Python feature and removes the GIL.

Just because you agree with part of my post and arguments doesn't mean you
have to downvote. I had the GVR quote about semver to directly responded to
and added to the original post, which is more than most comments.

Anytime I post something critical of Python3 it seems to be a big tug-o-war
between those who want to shame me and those who want to show approval. I do
it because someone has to say this stuff because I believe the silent majority
sees it this way and I frankly find the vocal Python3 promoters to be the
loudest of the bunch. There's nothing wrong with other viewpoints unless
you're wrong. :)

By the way, Mark Lutz is well respected. He has been teaching Python for
decades.

~~~
orf
> I wouldn't build any project in Python3 today, because the prod-ready PyPy
> option isn't there which adds CPU performance as a Python feature and
> removes the GIL.

But... that's a corner area of Python. Not everyone needs GIL-less STM, and
arguably if you're using tonnes of threads maybe you're doing it wrong?
Perhaps you should try asyncio :)

I mean that reason doesn't even make sense - I'm not using PyPy3 because of
the GIL. Great, so uhh what about Django apps? What about small scripts and
projects? What about using it for anything other than highly threaded
applications that benefit from no GIL?

> Just because you agree with part of my post and arguments doesn't mean you
> have to downvote

I didn't (and I wouldn't have), I just upvoted after reading "This being
another attempt to make Python2 look as old and crufty as possible" \-
thinking you viewed this in a positive light.

> frankly find the vocal Python3 promoters to be the loudest of the bunch

I see the opposite. I see lots of people angry about a statement being turned
into a function, angry at not understanding encoding and angry at the Python
developers. People demanding a JIT in cPython, people crying about type
annotations, etc. Plus a shedload of FUD.

I'm sorry, your comments reek of someone angry for not very good reasons and I
can't work out why. Python 3 is a much much nicer language to work with, it's
more consistent and has less WTF's (along with far less UnicodeEncodeErrors).
I took the plunge a year ago and won't ever look back, coding in 2.7-8 at work
hurts.

I know Mark Lutz is well respected but that doesn't make some of his comments
on Python 3 less silly. Anything that has been added to Python 3 has a comment
explaining why it sucks, and most of those explanations are senseless. Even
things like the statistics module - apparently that sucks because NumPy is
better? He implies that should be bundled instead. :/

The matrix operator saves 3+ lines of Numpy code (and is a common operation).
This of course sucks because "it's not used by the core language". Oh and it
"expands Python's complexity and learning curve needlessly", despite not being
used by the core language. Ok Mark.

~~~
BuckRogers
I understand your frustration, because I've never been able to see eye to eye
with Python3 folks either. I'm always searching for a convincing reason why I
need to stop using 2 and start using 3 but I have yet to find a reason that
makes sense considering what I lose moving from 2.

Example, I completely agree with all of Lutz's comments and can't see how
someone could see it another way. I'm trying though because I'd love to be
onboard (I'm sure Mark would too)- but I'd be lying to myself currently to
turn a blind eye and move to Python3.

On the benefits of Python2 having production-ready PyPy. It's more than GIL
free Python. You only discussed that, but the general performance is next-
level plus some from CPython3.

>Not everyone needs GIL-less STM,

You don't need anything, until you do. :)

>What about using it for anything other than highly threaded applications that
benefit from no GIL?

That's a "niche feature" like building async IO, but it actually matters
because Python3 cannot and likely won't have it. When it does, it'll most
likely remain 3.2. While Python2 has many ways to achieve async IO.

>Great, so uhh what about Django apps?

What about them? Django is dramatically superior on Python2/PyPy. I use Django
on PyPy with gunicorn and nginx and I assure you I have no worries about any
CPU bottleneck no matter what I do.

>people crying about type annotations, etc.

Most of the features in Python3 thus far have been gimmicks, and some are
downright embarrassing like type annotations.

Python2 is the premier development platform for me. I can use PyPy and I still
have the Python3 migration available. Why would I be in any rush when I only
lose moving to 3 today. It just doesn't make sense.

I find it amazing folks have been banging down the gates wishing there was no
GIL in Python- it's here but Python2 only. Therefore no longer a big deal. Not
to mention the pure single threaded CPU performance improvements available to
2. :) That to me reeks of pure desperation.

Frankly, the only possibility of an "upgrade" available from CPython2/PyPy is
not Python3. It's Go, Swift etc.

------
BingsF
There's no good reason for them to call it 4.0 instead of 3.10. This will just
result in even slower adoption.

------
Grue3
There isn't all that much code written for Python 3 to care about backwards
compatibility. IMO Python 4 should be:

\- backwards compatible with the latest release of Python 2

\- contain all features of Python 3 in some form

I think this will result in a very speedy adoption.

In the future I propose the following numbering scheme: for any N > M, Python
N contains all features of Python M and is backwards compatible with Python M
if and only if M divides N.

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

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

~~~
verbatim
Pick a Python 3 feature and let us know how you would implement it in Python
2.

~~~
Grue3
Easy.

Feature: print function.

Implementation: from __future__ import print_function

Yes, that magical, backwards-incompatible, print function has been in Python 2
all along!

Feature: unicode strings

Implementation: from __future__ import unicode_literals

Amazing! The magical, backwards-incompatible unicode strings backported to
Python 2 with one single line.

I could go on and on.

~~~
orf
> Amazing! The magical, backwards-incompatible unicode strings backported to
> Python 2 with one single line.

Except it's not even slightly close to that is it. unicode_literals is
something completely different.

How about removing old style classes? Is `class x:` old style or new style in
Python 2, in this imaginary interpreter of yours? How about the default object
comparison being sane in Python 3. How about the changes to builtins returning
iterables over lists? How about the import system being more sane? How about
removing backticks? How about _actually_ handling the unicode differences?

I could go on and on, and I hope your answer is not 'well we just need more
__future__ imports don't we'.

------
gweinberg
This is a joke, right? Obviously we can't write code that will work on python
4.

~~~
takeda
You can't write code that is guaranteed to work on Python 4, but you
definitively can write code that is guaranteed that _will not_ work on Python
4.

That's what this article is about, anyway. Based on the issues with Py3 I'm
quite confident that switch from 3 to 4 will be similar as from 1 to 2.

------
placeybordeaux
This seems like an unreasonable amount of time to dedicate to an uncertainty.

------
pvdebbe
And here I was getting excited about newest rumors on Python 4 features...

------
gipp
This post and thread are a trainwreck.

------
pricechild
How come the title was changed?

~~~
d23
The problem with changing this one in particular is that it actually makes the
author look more reasonable. I wonder if this would have nearly as many
upvotes with the absurd headline it was actually written with.

------
SixSigma
write your own vtable

    
    
        goto = {2:fn2, 3:fn3}
        if six.PY in goto :
            goto[six.PY]()
        else :
            sys.stderr.write("ack, no python to run!\n")
            sys.exit()

------
stefs
don't be silly - my code will long be replaced when python 4 comes out! it's
just a temporary hack/short term solution anyway.

~~~
therealmarv
This is what people said to themselves when Python 3 was at the horizon...

~~~
Scarbutt
That joke went way over your head.

------
gragas
This is ridiculous. I thought this would be a joke, but it doesn't seem like
one.

------
frik
Often I discover projects that are still in v2, and no words about v3 on their
roadmap.

Maybe v4 should learn from JavaScript5 and Visual Basic 3-6.

Support v2 syntax out of the box using a (slow) shim layer if there is no

    
    
      "use strict"
    

in the first line. If that statement is present, don't load the shim layer and
support only v4 syntax (faster).

That way old v2 code would still work without any changes.

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

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

~~~
herge
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/](http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/)

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

~~~
andreasvc
Nice flame bait. Don't see how it matters whether it is decided at runtime or
compile-time. Incompatible versions are a fact of life, and nothing particular
of Python.

------
xyzzy4
Why don't they just stop changing the syntax? They already ruined print
statements. Don't engineers have better things to do?

~~~
icebraining
This has nothing to do with changing the syntax, it's a problem even if Python
4 has the exact same syntax and APIs as Python 3.

------
pearjuice
To be honest, I am quite surprised that even in Python 4 whitespace is still
an integral part of the syntax.

~~~
CamperBob2
Too many egos at stake, at this point. Whitespace will always be syntactic in
Python because nobody with any influence wants to admit it's a mistake.

~~~
andreasvc
That's not an argument, you could say the exact same thing about braces in
other languages. Truth is, it's something that works that really doesn't need
to be debated to death like it is.

~~~
CamperBob2
Yet strangely, hardly anyone complains about braces. I wonder why?

~~~
andreasvc
Well I think they're annoying, but there's not much point in complaining
because it's not going to change overnight. Either way syntax is a very
superficial aspect about programming languages, more interesting to consider
semantics.

------
pbreit
Maybe Python 4 will be properly compatible with Python 2?? Kidding.

But more seriously, probably good advice. Isn't "explicit" one of the Pythonic
mantras?

But I'm wondering if any code written today really will survive until "Python
4"?

~~~
dyladan
I would certainly hope code written today at least _could_ last until python
4. The idea that everything has to be rewritten just because of a language
version bump is a flawed thought process IMO.

------
Animats
Do we _need_ Python 4? How about just extending Python 3 incrementally?

 _Stop Python 's little tin god before he kills again._

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

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

~~~
ssunstruck
I'm not entirely sure if this is sarcasm...

