
Moving Away from Python 2 - ngoldbaum
https://asmeurer.github.io/blog/posts/moving-away-from-python-2/
======
21
I've seen this story happen twice before.

20 years ago there was this great MP3 player, WinAmp 2. And then they released
WinAmp 3, which broke compatibility with skins and plugins and which was slow.
People didn't upgrade. Finally, they came to their senses and they released
WinAmp 5, marketed as 2+3, which was faster and brought back compatibility
with older stuff.

In the retail trading Forex world, there is this great trading app called
MetaTrader 4. Many years ago they released MetaTrader 5, which broke backward
compatibility and removed some popular features. People didn't upgrade. Today,
they are finally bringing back the removed features and making MetaTrader 5
able to run MetaTrader 4 code.

Me, I wait for Python 5 (=2+3) which will be able to import Python 2 modules,
so that you can gradually convert your code to the newer version.

I have tens of thousands of lines of Python 2 code in a big system. I can't
just take 2 months off to move all of it to Python 3. Moving it in pieces is
also not really possible, since there are many inter-dependencies.

Uglyfying my code with the "six" module it's also not a solution, since when
I'll move, I won't care about Python 2 anymore.

So basically I'm just waiting until a consensus emerges.

It should be noted that the quantity of Python 2 code keeps on growing, I
wrote most of my code while Python 3 existed. If Python 3 allowed an easy path
forward, we wouldn't be in this situation.

~~~
klodolph
All of the reasonable "2+3" features in Python have already landed, like u''
strings in Python 3.3. The really big issues, like the difference between
strings and bytes objects, can't really be emulated away. This isn't like
WinAmp or MetaTrader where you can just reimplement the old interface in the
new application. Code that mixes strings and bytestrings freely is simply not
going to interface well with Python 3 code.

There are few paths for upgrading. You haven't mentioned 2to3, but I will.
I've migraded projects of the same size you mention (10s of kloc) with 2to3
and the process took days, not months. About three days with one developer,
actually.

There are a number of projects which also have code bases which are compatible
with both Python 2 and 3. You say that once you move, you won't care about
Python 2 any more, but I that's not a good reason to reject six outright. In
my experience, the code isn't really "uglified" but there are just a few minor
cases here and there you need to think about.

Anyway. Small-ish projects like the one you are talking about are usually not
as hard to migrate as you might think. There are some exceptions, of course.

~~~
21
I agree that the bytes/string problem is a tough one. But the dev team created
it and dropped it into the laps of it's users.

The Windows API had the same problem, it was ASCII and then they added
Unicode. But instead of just forcing your app to exclusively use a single one
of them (sort of like use Py2 OR Py3), they allowed you to mix and match your
code, and call either the old or the new version of the API. And gradually,
people stopped using the older version and started using the Unicode one.
Today, new Windows APIs are strictly Unicode.

Of course, the solution was ugly from their side, having 2 duplicate APIs for
the same thing, but it didn't brought pain to their users and allowed them to
proceed at leisure.

~~~
kstrauser
So, it's like Python. You can still mix and match; you just have to explicitly
convert between them at the appropriate points.

The main breaking change is that you can't read a stream of bytes from a byte-
oriented resource (say, a network connection that by definition can only send
a stream of octets) and magically treat it like text elsewhere. While that's a
tempting thing to want to do, it's been an unending fountain of bugs over the
years. For example, in Python 2.7:

    
    
      >>> a = 'this is a test ಠ_ಠ'
      >>> b = bytes(a)
      >>> b
      'this is a test \xe0\xb2\xa0_\xe0\xb2\xa0'
      >>> type(b)
      <type 'str'>
    

In Python 3.5:

    
    
      >>> a = 'this is a test ಠ_ಠ'
      >>> print(a)
      this is a test ಠ_ಠ
      >>> b = bytes(a)
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      TypeError: string argument without an encoding
      >>> b = bytes(a.encode('utf-8'))
      >>> b
      b'this is a test \xe0\xb2\xa0_\xe0\xb2\xa0'
      >>> type(b)
      <class 'bytes'>
    

In 2.7, you encode a series of Unicode values back to... a string? This is the
source of all kinds of fun as functions expecting a string as input don't have
a way to tell whether it's already been encoded or if they need to do so. In
3.5, there's no ambiguity. Functions that write to files or network sockets
can either receive strings and know that they have to encode the strings
locally, or bytes and know that they don't have to.

Right up near the top of Zen we get:

    
    
      >>> import this
      The Zen of Python, by Tim Peters
    
      Beautiful is better than ugly.
      Explicit is better than implicit.
    

The Python 2-style implicit conversions were awfully convenient 15 years ago
when most things were ASCII. They're absolutely painful now that we've moved
past the expectation that strings are arrays of single bytes.

~~~
tomjen3
It may just be me, but I tend to assume all strings are UTF-8.

~~~
Animats
The problem is that Python Unicode strings are indexable with integers. They
support random access. Each element contains one character, not one byte. The
implementation chosen for Python 3 is to handle them as arrays of 1, 2, or
4-byte items, automatically expanding the characters based on the widest
character in the string. In Python 2, the options were to build the
environment for 2 byte or 4 byte Unicode characters.

This could have been done differently. I would have been tempted to store
strings as UTF-8 in Python 3, but hide this from the user. Most of the string
functions, including regular expressions, don't really random access a string;
they're sequential and forward only. They could work on UTF-8. The ones that
return a string index should return an opaque type (say, "StringPos") which
has a reference to the string and a position in it. The string functions
should accept that type as an index.

If someone applies "int()" to a string index, or performs arithmetic on it, or
indexes a string with an actual integer, then it's necessary to scan the
entire UTF-8 string and create an index of where each Unicode character
starts. This should be a rare event. Especially if there's support for adding
or subtracting small integers from a StringPos by walking the string forwards
or backwards, rather than building the full index.

Examples:

    
    
       s = "This is a test" # Unicode string, internal represention UTF-8
       i = s.find("is")     # returns a StringPos, not an int.
                            # no need to index the string for any of these
       s1 = s[i]            # StringPos selects the char found by find
       s2 = s[i:]           # No need to build an index for this
       s3 = s[i+1:]         # Adding a small int just walks the string
                            # these force generation of an index 
                            # the first operation like this on a string is expensive
                            # comparable to a UTF-8 to rune array conversion
       j = int(i)           # converts a StringPos to an int 
       s4 = s[i*2]          # again, expensive
    

In practice, those expensive operations are rare.

This would cut Python memory consumption way down when processing mostly-ASCII
Unicode data. It would also make it more efficient to input and output UTF-8,
which is usually what you want.

~~~
firebones
I recognize your name as a rustacean, and since I'm someone who reluctantly
had to add some unsafe code to extract a substring due to graphemes being
unstable, I'm surprised to see you take shots at the Python model.

(Granted, I'm still learning, so maybe I can be as efficient without relying
on unsafe, but still...)

~~~
Animats
I'm a Rust user; I'm not involved with its development. I had dinner with some
of the main developers once; that's about it.

------
kstrauser
I'm so glad to see this. I started with Python 1.4, and after several years
too long on 2.6+ I've just recently been able to convince an employer to start
a new codebase on Python 3.5. Having used it in production now, I would not
willingly go back. Python 2.7 is excellent, but Py3 feels like "Py2 done
right". It's at least as nice in every way and much nicer in quite a few.

I'm in a shop with solid microservice underpinnings, so our new project could
just as easily have been in Go or something else for all its clients would
know or care. Given that all the libraries we wanted to use were already
available for Py3, this was a no-brainer. There were plenty of reasons to
upgrade and no compelling reasons to stay on Py2. Should you find yourself in
such a situation, I highly recommend investigating whether you can make the
same move.

~~~
albasha
Which framework are you using for the said microservice?

~~~
kstrauser
Flask + Flask-RESTful for this one.

------
Animats
The Windows 10 approach - apply pain to the users until they "upgrade". Python
3 hasn't made it on its own merits, and we have fanboys like this trying to
figure out some way to force people to upgrade.

Library porting to Python 3 did not go well. Many Python 2.x libraries were
replaced by different Python 3 libraries from different developers. Many of
the new libraries also work on Python 2. This creates the illusion that
libraries are compatible across versions, but in fact, it just means you can
now write code that runs on both Python 2 and Python 3. Converting old code
can still be tough. (My posting on this from last year, after I ported a
medium-size production application.[1] Note the angry, but not useful, replies
from Python fanboys there.)

Python 3, at this point, is OK. But it was more incompatible than it needed to
be. This created a Perl 5/Perl 6 type situation, where nobody wants to
upgrade. The Perl crowd has the sense to not try to kill Perl 5.

Coming up next, Python 4, with optional unchecked type declarations with bad
syntax. Some of the type info goes in comments, because it won't fit the
syntax.

 _Stop von Rossum before he kills again._

[1] [http://www.gossamer-
threads.com/lists/python/python/1187134](http://www.gossamer-
threads.com/lists/python/python/1187134)

~~~
cvwright
What kills me is, they decided to make breaking changes, and they still kept
the damn global interpreter lock! It's like saying "Sorry guys, it's 2016, and
you have to port all your code, but no parallelism for you!"

Beatings will continue until morale improves...

~~~
anderspitman
I'm not aware of any popular scripting language that supports utilizing
multiple processors without starting new processes. Is this a thing? I don't
do a lot of parallel stuff with Python but multiprocessing has met my needs.

~~~
dalke
"Jython and IronPython have no GIL and can fully exploit multiprocessor
systems" \-
[https://wiki.python.org/moin/GlobalInterpreterLock](https://wiki.python.org/moin/GlobalInterpreterLock)

Granted, neither implementation has the popularity of CPython.

~~~
toyg
And both are sadly stuck on Python2, last I checked :(

------
danso
Just to add some perspective from another language: Ruby had a similar,
traumatic rift when transitioning from 1.8 to 1.9. I don't think it's a
coincidence that -- like Python 2.x to 3.x -- Unicode-handling was one of the
changes...so even though Ruby 1.8 to 1.9 had fewer compatibility breaks than
Python 2.x to 3.x, it still pissed off a lot of people.

But what made the community jump, IMO, was the fact that the Rails maintainers
announced that they would be upgrading to 1.9 [0]. And since there is a very
small subset of Ruby users who _don 't_ use Rails, that was the end of
discussion.

Is there any library in Python that enjoys as much dominance over the language
as Rails does to Ruby? Not from what I can tell...And virtually all of the big
mindshare libraries in Python have made the transition (e.g. NumPy,
Django)...So I agree with OP that making libraries commit to 3.x-or-else is
the way to encourage adoption of 3.x...but I just don't see it working as well
as it did for Rails/Ruby. That's not necessarily a _bad_ thing, per se, in the
sense that it shows the diversity of Python and its use-cases, versus Ruby and
its majority use-case of Rails. But forcing the adoption of a version upgrade
is one situation in which a mono-culture has the advantage (also, see iOS vs
Android).

[0] [http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-
on-r...](http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-ruby-1-9/)

~~~
Freaky
Ruby 1.9 rewarded your upgrade efforts by running twice as fast. There was a
lot of enthusiasm to migrate.

Python 3 still seems to reward you by running slightly slower. Where's the
hook? Marginal improvements to language design are bit of a weak sell for a
language that's already pretty nice.

~~~
wbond
All of the testing I've done with real-world code has shown an improvement of
10-20% moving from 2.7 to 3.4. I believe 3.5 made some slight further
improvements.

~~~
BuckRogers
If only CPython3 wasn't completely blown out of the water by Python2's
production-ready PyPy. That said, my tests are the exact opposite of what
you're claiming- I've been doing the same benchmarks on all the CPython3
releases since 3.2. I think you're the only person I've heard make that claim
in fact.

------
wyldfire
> For SymPy, the fact that 1/2 gives 0 in Python 2 has historically been a
> major source of frustration for new users.

I love Python, and I think Py3k is great. But I guess I have written too much
C/C++ or something because integer division yielding integers (implicitly
"with truncation") is what I would expect and not a float. And I'm a big fan
of the "Principle of Least Surprise" but in this case I'm surprised to see
int/int give float.

But, hey, like I said -- Py3k is a net improvement. And I'm sympathetic to new
programmers and I love that Python's so popular for those new to coding.

~~~
yk
Usually I would agree, but it is written in the context of SymPy, as symbolic
math library. There I would expect 1/2 is the solution to 2*x=1 .

~~~
fdej
On the other hand, 1/3 is still not the (exact) solution to 3*x=1...

~~~
lrem
But it can be done, even in systems implemented in Python 2. Try the following
in [http://sagecell.sagemath.org/](http://sagecell.sagemath.org/)

x = 1/3 3 * x == 1

~~~
williamstein
1\. I introduced the "Sage preparser", which does things like replacing "1/3"
by "Integer(1)/Integer(3)" in Sage, before feeding that input to Python to be
evaluated; Robert Bradshaw also did a lot of work on the preparer. The
preparser uses a hook into the IPython evaluation system. I decided I really
needed Sage to use a preparser like this during a talk I gave at Pycon 2005,
based on audience feedback, which is why it exists.

2\. I would _really_ like somebody to remove the preparse code from Sage and
make it a standalone library available on pypi. Here's the code (happy to
relicense it under BSD):
[https://github.com/sagemath/sage/blob/master/src/sage/repl/p...](https://github.com/sagemath/sage/blob/master/src/sage/repl/preparse.py)

3\. Permalink to your example --
[http://sagecell.sagemath.org/?q=nwzdzn](http://sagecell.sagemath.org/?q=nwzdzn)

------
jedberg
Part of the problem is that the big hosting services don't even support Python
3 yet. Google App Engine and AWS Lambda don't support it, Heroku does but only
for the past year, etc.

I'm building a brand new company and I'm being forced to use Python 2.7
because I'm using Lambda. This was my choice, but the point is I can't use 3
even if I want to.

~~~
SiVal
That would make me pretty nervous. A couple of years from now, it will be
taken for granted that all new Python projects are written in Python 3, and
AWS Lambda will either be obsoleted by a Python 3-based competitor or--about
the time you get your code built out--they will announce with great fanfare
that Python 3 is their future and put projects like yours on the B Team's
legacy infrastructure.

After "forcing" you to build your company on Python 2, they'll build theirs on
Python 3 and too bad for you.

~~~
jedberg
I'm not too worried -- we write all our code with Python 3 in mind (and import
future) so the transition will be easy. It's just frustrating when I can't
take advantage of some of the newer language features.

------
rahiel
> Python 2.7 support ends in 2020. That means all updates, including security
> updates. For all intents and purposes, Python 2.7 becomes an insecure
> language to use at that point in time.

There are alternative python implementations like pypy, and they haven't
expressed an intent to drop python 2.7 support. Only CPython 2.7 will then
become an insecure interpreter.

~~~
nas
If you think Python 2.x support ends when the core team stops supporting it,
you haven't been studying history. Programming platforms with large code bases
(e.g. Cobol, Fortran) have extremely long lifetimes. What's more expensive:

1) porting millions (possibily billions) of lines of working Python 2.x code
to Python 3

2) keeping the Python 2.7.x interpreter in deep maintenance mode?

This idea that you can _force_ people to move to Python 3 keeps coming up and
is misguided, IMHO. There are two proper solutions to this issue:

1) make it easier to port from 2.x to 3.x. We are still making progress.
Python 3.5 includes %-style formatting for byte strings. Allowing 'u' as a
prefix for strings was another example. Practicality beats purity.

2) make 3.x a more compelling platform for new development. The amount of
goodies in 3.0 was pretty underwhelming. I certainly wasn't very excited about
moving to it. Async IO is a neat feature. Keep them coming.

~~~
bjt2n3904
This is the problem with Python 3. The arrogance of the people in support of
wrestling it from us.

> Frankly, if these "carrots" haven't convinced you yet, then I'll wager
> you're not really the sort of person who is persuaded by carrots.

As someone that uses Python as a C replacement for one-off-scripts that work
with binary objects and pure ASCII, Unicode is not a carrot. Unicode will
never be a carrot. If anything, Unicode keeps me away.

If I was developing web apps, GUI programs, or data processing libraries,
sure. These would all be carrots. But I'm not. The simplicity of Python 2 is
my carrot.

> Python 3 does have carrots, and I want them.

You have them. But you seem to be more interested in taking away my carrots,
so you don't have to worry about them any more. That's arrogance.

------
hartator
I still don't get why they are noy just backporting the simple things people
are missing. Like breaking: print "hello". I don't think being academically
correct is worth the current schism.

~~~
kstrauser
That's far and away the easiest transition: start using parens in your Python
2.7 code today and you won't have to alter them when migration day comes.

~~~
iak8god
And use __future__ to force yourself not to forget:
[https://docs.python.org/2/library/__future__.html](https://docs.python.org/2/library/__future__.html)

------
pnathan
Nah, I'm good. Python 2.7 is not going to change. I have zero desire to port
my code and gain zero benefit. I can actually write Python 2.7 with confidence
that invoking "python2" won't break on the next rev of the OS.

Most likely, if CPython & crowd give up on 2.7, PyPy will carry the flag of
"Stable Python" forward and that'll be that.

But if Python dies, I won't really be sad. Better languages are out there. :)

~~~
RussianCow
> But if Python dies, I won't really be sad. Better languages are out there.
> :)

Like what? I'm curious, because I've tried a lot of the newer languages out
there, and I haven't found a general purpose one that I like nearly as much as
Python. Elixir is really cool, but it has a pretty narrow focus, which makes
it difficult for me to make the investment in learning it.

~~~
jdimov9
Elixir _is_ the correct answer. Not sure what you mean by "narrow focus" \- it
is as general purpose as anything. Only thing holding me back from fully
moving from Python to Elixir is that the ecosystem isn't mature enough yet.

~~~
zeemonkee3
I like Elixir, but the ecosystem has years of catching up to be anywhere close
to Python. Not just libraries but experienced developers. There's also a
danger it might end up like Ruby - basically the support system for a web
framework.

~~~
true_religion
Elixir is nice, but I hardly think it compares to Python due to the fact that
you are _required_ to hand back control from a native call approximately every
half second or so or else you will screw the internal scheduler on the
ErlangVM.

------
BuckRogers
Why does this guy care if others don't drop Python2 support? Instead, live and
let live.

Everyone is going to use what they want. People have been whining about this
for almost a decade now, give it up. This community isn't going to be on one
version again, and that is NOT the community's fault. It's the core dev team
and Guido's for poor decision making, technical churn and refusal to go back
and fix their mistakes. There's no technical reason why CPython can't run
Python2 and 3 code, JVMs and the CLR have proven this sort of thing is
possible.

If there's not strong enough support of Python3, let it die. Technical churn
is not supposed to survive, not live on propaganda and coercion. I don't see
the problem. If he bought into 3 before it succeeded, he created his own
problem. I plan on porting what I have over when 3 actually gets over the hump
but not before. That's what's in my best interests, which is what everyone
should do (and it's exactly what the core dev team and GVR did).

Besides, if you're not into numerical Python and mainly use it for web, PyPy
makes more sense to migrate to than Python3.

~~~
akubera
> I plan on porting what I have over when 3 actually gets over the hump but
> not before.

Don't you think that mentality is part of the problem?

~~~
BuckRogers
No, because as I noted in the parent- I disagree with your premise that there
is a problem. This is how open source works, failed ideas are allowed to fail.

~~~
stoptheworld11
That may be true in the case of smaller open-source things. But when it comes
to larger projects, it's largely the same way as it is in the rest of our
society: things that are considered too important to the whole are changed
regardless of pushback.

Not a big deal if something like screen dies or fades. But the same is not
true of something as big as Python.

Open-source is democratic in that you have a voice, but it doesn't mean your
opinion matters much in certain cases.

Python2 hardliners have been warned for years. By the time it is sunset it
will have been 12 years since it's release. Why should the Python devs stop
moving their project forward because you're not interested refactoring and
deprecating old code?

Where I work we move forward and adapt our code/patterns over time. If an old
thing breaks (due to updating to Py3 compatible features), we
deprecate/replace or refactor it to work, whichever the team decides holds
more value for us as a group. There's probably very little code in there that
was written 8 years ago when Python3 dropped. We iterate forward.

I get pretty frustrated by this "but this stuff I wrote a decade ago works and
I don't wanna..." attitude in the tech world. Not saying people should burn
the candle at both ends to keep up, but come on. 12 years and you can't
refactor forward? Then you find yourself in a position where, oh shit we
really have to burn the candle at both ends.

This isn't about the actual work involved then. Because you're going to write
code anyway. It's about not wanting to change your headspace (not all that
much, esp for experience programmers) to write Python3 compatible code. The
burden then is on Python hardliners to keep up or fade away, much in the same
way you suggest.

Old is replaced with new. It's the way the world works. Get over it.

~~~
BuckRogers
Throwaway account created just for that? A lot of words to say nothing other
than you're pissed off and are disconnected from the real world of software
development. Python2 means more than Python3 does: AWS matters, GAE matters,
1000KLOC+ matters, 50K long-tail of libraries on PyPi matters, PyPy matters.
You must be new. Why not reveal your real account instead instead of hiding
behind a pseudonym.

Bottom line is that you believe newer is always better. That's not true at
all, especially in programming languages.

------
skizm
It is pretty simple: when I spin up an EC2 instance on amazon, and I type
"python" in the console, whatever version that is will be the version I use.

~~~
lima
Nowadays, I no longer use the distribution Python at all.

Debian Stable and pyenv it is. That way, I have a rock solid operating system
and my application are completely decoupled.

Using distribution packages for application deployments is insane. It makes
sense for workstation or systems software where the application you develop is
part of the operating system, but for a server application, it makes no sense
at all.

~~~
matt_wulfeck
They aren't completely decoupled. Even with a virtenv you still need to
install and maintain a lot of library and header packages on the host OS.

~~~
Filligree
For _complete_ decoupling, better use NixOS.

~~~
lima
Or Docker containers :-)

------
jtchang
I am so annoyed at Python for not having a good upgrade path with backwards
compatibility. Even with iOS you can use Swift code along with ObjC.

~~~
xapata
I haven't had trouble upgrading. What issues are you encountering?

~~~
joobus
Twisted doens't support py3.

~~~
reubano
That's only half true [1]

[1]
[https://github.com/twisted/twisted/blob/twisted-16.2.0/twist...](https://github.com/twisted/twisted/blob/twisted-16.2.0/twisted/python/dist3.py)

------
noisy_boy
As a developer, it is difficult for me to move to Python 3 (and I want to).
I'm working on a Django project and relying heavily on various Django plugins.
There are a whole lot of plugins that are only supported for Python 2. Without
much knowledge of Django landscape, I anticipated this and went with Python
2.7. Turned out to be a prudent decision that saved me tons of time.

~~~
rspeer
Interestingly, Django is one of the big projects that has already announced
they're dropping Python 2 support before 2020. Django 1.11, to be released in
April 2017, is scheduled to be the last version to support Python 2. [1]

They've prudently made their last Py2 release a long-term support release, but
if you want new Django features after December 2017, you're going to be using
Python 3.

Django works great on Python 3, BTW, and if you've got plugins that haven't
updated, I would recommend being a bit suspicious of their code quality.

[1]
[https://www.djangoproject.com/weblog/2015/jun/25/roadmap/](https://www.djangoproject.com/weblog/2015/jun/25/roadmap/)

~~~
0xADEADBEE
If it helps anyone, 1.8 works with 2.7 and was an LTS release, which is
supported until April 2018. You don't get the cool new features like Channels
out of the box, but they're available via third parties.

------
overgard
I think it's instructional to consider what happened to Microsoft with Windows
8 here. They offered a product that users were utterly ambivalent about, and
took a hardline "no debate, that's just how we're doing it" stance. And it
totally flopped. So they offered some concessions in Windows 8.1, but by that
point the narrative on Windows 8 had already formed and the brand was
tarnished. So what was the fix? Windows 10. Arguably 10 isn't actually that
different from 8 (I mean yeah, it's better, but if you installed a start menu
in 8 it's really not that different). I think Windows 10 worked because by
being a new windows, it got to form a new narrative separate from windows 8.

The way I see it, Python 3.4+ is a lot like Windows 8.1. It's actually really
not bad, but the narrative around its predecessors will never let it truly
succeed. The realistic way for python to move forward is to offer a brand new
version (5 or 4, doesn't really matter), give some concessions to the python 2
people that will make them feel heard and feel reinvested (bring back the
print statement, give us some long wanted things like not-stupid lambdas), and
guarantee python 3 compatibility so they're not forking the damn project
again.

I think at this point so many people have said bad things about Python 3 that
the brand is toxic. A new version number might not really mean much
technically, but symbolically as a sign to the python community that the devs
have finally stopped being stubborn and arrogant and acknowledged they fucked
up, it would be huge.

------
noobiemcfoob
Is this really still so much of an issue? I switched to Python 3 some years
ago and haven't even considered going back.

I can't say I've come across an issue caused by an incompatibility between the
two since the first couple months after switching...

~~~
dkarapetyan
You must be in a very luxurious position then to not have to work with any
legacy code base. The reality is that there are some giant python 2.7 code
bases with forked versions of some major frameworks and libraries. There's no
way in hell these places are going to migrate to Python 3 any time in the next
decade.

------
stesch
The people who really decide what you do don't care about syntax. They'll ask
you if it is faster. And Python 3 is even slower than Python 2.

You don't have this problem with PHP. "Hey, Boss! We need to rewrite our code
for PHP 7." – "Will it be faster? How much?" – "It will be faster. By factor
X." – "Go on, make it so."

~~~
unlinker
That's a good point despite the downvotes. If you don't need any of the Python
3 goodies, by upgrading you will make your code run even slower. Hard to
justify.

~~~
takeda
If you care this much about performance, python is most likely wrong language
for you, you should try statically typed languages instead.

------
SFJulie
What about the open source developers that have been tired of the messy
experience of python3.2 packaging?

That are doing this as a hobby. And don't have extensive time.

Why guilt us?

We are neither companies nor fundation's bitch.

Packaging in python is a mess, and every one wants to contribute to the shiny
new features, and very few have to deal with the toilet cleaning that
packaging (pypi, deb, rpm..), maintaining, dependency management, bug report
platform consistency involves.

I am a bored as a maintainer to be expected to deal without a thanks for all
the shit coming from the social pressure of "you should do this or blah" to
comply with esoteric unproven needs that only results in more work and just
more mess and layers of bureaucratic ideas disguised as "best practices".

I am no one's bitch. I am an open source coder. I code what I want, when I
want, at the speed I want, and I am no slave that will do what he is being
ordered.

------
incepted
I have a feeling that by the time this happens, a lot of the Python developers
will have moved to Go or some other language.

------
jamwt
Python 2 isn't going anywhere so long as the multi-million line 2.X codebases
at big tech companies exist. Every big Python codebase I'm aware of is 2.x.

------
nelmaven
This sort of war between Python 2 and Python 3 is why I never looked seriously
into Python. I don't know where should I start.

~~~
mixmastamyk
Python 3.5, installed by default on LTS distributions, and available
everywhere else.

~~~
nacs
Output from my systems right now:

"Ubuntu 15.10" \- Python 2.7.10

"Ubuntu 14.04.4 LTS" \- Python 2.7.6

Not sure where you're getting the "by default 3.5" from.

~~~
mixmastamyk

        ＞ python3 --version
    

Or:
[http://packages.ubuntu.com/xenial/python3](http://packages.ubuntu.com/xenial/python3)

------
carapace
Please stop working so hard to piss in my soup.

I plan to keep using Python 2.* until the sun grows cold or I die (whichever
comes first.) So this entire effort seems like a busybody with nothing better
to do working hard to screw me over.

Knock it off!

------
green_lunch
I finally was able to start new projects in Python 3 because most major
libraries are compatible.

------
TorKlingberg
Is there any reasonable measurement of Python 3 market share? I guess it's
still <25%.

~~~
karim
No there isn't. People used to be able to extrapolate it from the pypi
downloads stats (like this: [https://alexgaynor.net/2014/jan/03/pypi-download-
statistics/](https://alexgaynor.net/2014/jan/03/pypi-download-statistics/)),
but sadly it's not possible anymore.

~~~
hacst
There is [https://caremad.io/2015/04/a-year-of-pypi-
downloads/](https://caremad.io/2015/04/a-year-of-pypi-downloads/) which is
also based on PyPI downloads and is more recent.

~~~
karim
Oh, thanks! It's kind of crazy to see Python 3.x usage stuck around 7%,
though.

~~~
kstrauser
Note: that's from a year ago.

------
carlsborg
Its hard. Imagine you are a Fortune100 company with a 3 Million line code base
running critical financial systems off a python 2.7 application framework...

~~~
natch
Not so long ago they were saying this about COBOL.

When there is a competitive advantage to adopt the latest best practices, they
will. Maybe not this year, but the day will come when even the legacy python
developers will jump.

------
melling
There's a yearly discussion about moving from Python 2 to 3.

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

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

It's not a very productive use of time.

~~~
rcarmo
I thought it was monthly. Seems to happen around the 20th each time, every
time a Python piece gets posted...

------
kinkdr
And this exactly is the beauty of free software. The core team is free to drop
support or do whatever they want. One thing they cannot force people to
upgrade. They will upgrade when they want to upgrade.

Personally I tried upgrading a couple of times, but partial or no support of
Python 3 from libraries I depended on, stopped me from doing it.

------
transpy
For us beginners, professionals from other areas that want to use Python as an
additional tool, this situation is quite confusing. I'm doing Python MOOCs and
most of them focus on Python 2. I don't have a massive code base to maintain
like most of you, I just would like to know what path to follow, Py2 or jump
already to Py3.

~~~
SiVal
There are old, but still good and sometimes best, learning materials for all
mainstream languages. That creates a challenge for learners, because learners
should be focusing on the future of the language, not its past. If you're
learning C++ now, you really should be learning the C++1x style of writing it;
if you're learning JavaScript, it should be ES6-style; and if you're learning
Python, it should be Python 3.

The older styles of these languages are still relevant to those who will need
them for professional use on older code bases, but for a new user, they can be
treated as more advanced material to be learned primarily for recognition but
not for writing.

Learn Python 3 now; add some Python 2 details later, if needed. And if you
really love your Python 2 MOOC, go ahead and use it as an introduction. Almost
everything they are showing you is both Python 2 AND Python 3, so you're
learning Python 3. Then move on to intermediate-level material that is Python
3 and goes into a lot more detail, and you'll easily switch over.

------
PunchTornado
I don't think the same issue will happen to with PHP7 because PHP7 offers
performance improvements.

When talking to management or client it is useless to name any design
improvements, but as soon as you mention speed they will say "yes, let's do
it".

The issue with Python 3 is that the performance is not that much better.

------
dendory
Guess it's luck that I started using Python when they released 3, and went
straight for that!

------
dkarapetyan
Basically this is an excellent case study of how not to do a major migration
from one version of a language to another. There is no way in hell places that
have forked versions of libraries and frameworks like django are going to move
to python 3, ever.

------
0xADEADBEE
\- [ ] I've been developing with Python 2 for 8 years now, and I take umbridge
at the upgrade. Python 3 introduces a variety of breaking changes but in
contrast to other comments, this is great. Python 2 has a litany of mistakes
in it (ever try a listcomp using a previously declared variable name as the
intermediary? Watch that get clobbered when block-level scoping decides it
doesn't fancy it; there are many more similar examples), some of which are
mercifully fixed in 3.

For me though, what's the point? I like that lru_cache is a convenient
decorator rather than having to roll my own memoisation and that some
relatively solid steps have been made towards async programming but that's
about it. Its not like the changes were things that couldn't be achieved
before (Twisted is solid, from what I have seen so far). I still have to
factor in the GIL if I want performance to a certain point (dual core
processors have been around for almost two decades now - I am starting to
question why cPython is even considered a serious choice for use cases where
prod has more than one core).

More crucially though? The APIs. camelCase features heavily (in spite of
PEP8), the principle of most surprise is rampant (I recall last week
discovering a function signature with infinite arity rather than passing a
collection, like, you know, every other Python method) and SO many more warts.
When interacting with a file, try and guess what you want: "readlines? Doesn't
load each line into collection, which is what you'd expect. writeline? Be sure
to manually interpolate a \n because in contrast to the name, it's actually
going to insert everything on the same line because... well, who knows.
writelines? Well, you know how in Python you usually iterate over over thing
and handle it? Well here, you pass a collection. There's a corresponding read
meth... No there isn't". If we're introducing breaking changes, how weren't
these things fixed? You either commit to breaking changes or you don't make
any - py3 trod the line somewhere in the middle and is paying for it with its
adoption numbers. The broader point is that this mess is exactly why we all
love libraries like requests. If Python were a Fortune 500 company, GvR would
have been ousted as CEO long ago, and rightly so.

As a contractor, I have to absorb this new way of doing things in case I find
a job that actually requires Py3 knowledge (in the UK at least, these are less
frequent than HN prefers to make out) because my marketability depends on it.
That said, although I'm currently contributing to Pypy, I realistically see my
future in Clojure, Ruby, Elixir or some other language that I'm prepared to
put the time into picking up, in contrast to Py3, where I see missteps and
hamstrung APIs as active disincentivisation to my learning. Any half decent
dev will just move on, because why would they put up with this? Did we not
learn anything from PHP?

------
metalliqaz
I'll transition when pypy transitions.

~~~
reubano
[http://doc.pypy.org/en/latest/release-
pypy3-2.4.0.html](http://doc.pypy.org/en/latest/release-pypy3-2.4.0.html)

~~~
BuckRogers
It's well-known that PyPy3 is not production-ready. I've spoken with them
about this many times over the years and it's not being worked on like PyPy5
is.

------
nurettin
> the fact that 1/2 gives 0 in Python 2 has historically been a major source
> of frustration for new users.

Yes. Imagine the bewildering inconsistency when a newcomer who tried any of
pascal, c or a myriad of other languages try their hand in python.

------
njharman
Python 2 is not only legacy it is deprecated.

------
Bromskloss
I want Python 4 already!

------
rjurney
What an idiotic idea. Python 3 needlessly broke things for features that did
not really improve the language. Python 3 is a dead end. The 'slated' end of
2.7 won't happen, just the project leadership will change.

------
ismdubey
You know what will make the transition faster ? Amazon. Reasoning below.
Developers care about building things (not talking about core python team but
app developers like you and me). Most of them use AWS linux and by default it
comes with Python 2. This is why most of the developers keep using python 2.69
or 2.7. If AWS Linux by default changes to Python 3, the game will change. In
my view, better petition Amazon to do it :)

