
Migrate to Python 3 Now, There's Little Time Left - eriky
https://medium.com/better-programming/why-you-must-migrate-to-python-3-now-2a2729631a22
======
jdormit
> It's not hard to upgrade your code

People keep writing blog posts about how easy it is to migrate your code, and
I just can't imagine that these people have any experience maintaining a
Python2 codebase outside of toy projects or libraries.

At work I maintain a Python2 codebase that's been under development since
2016. It's huge, relies on now-deprecated Py2-only libraries that we can't
realistically switch away from, full of Py2-specific syntax, and reliant on
Py2's handling of Unicode strings. We scoped out what it would be like to
upgrade it to Py3, and determined that we would basically need to rewrite
large parts of it from scratch. This isn't an acceptable trade-off for the
business in terms of development time and priorities.

Instead we are slowly breaking out the monolith's functionality into Py3
services, which is much more tightly-scoped (and more palatable for
management). But realistically speaking we will be maintaining Py2 code for
the foreseeable future, and I can't imagine we are the only company in this
situation.

Upgrading a production codebase from Py2 to Py3 isn't easy, or even possible
in some cases. And frankly, all these blog posts suggesting that migration is
trivial are insulting.

~~~
joshuamorton
95% of the migration effort is trivial (I say this as someone who has migrated
100k+ loc myself as part of a much larger migration effort).

There's things that are tricky, don't get me wrong: unicode handling can be
tricky, though six.ensure_str/bytes usually allows you to defer that problem.
Futurize and 2to3 do _so much_ of the work that in my experience the majority
of files can be migrated by automation, unicode warts included.

The hard stuff is when you have extension modules or weird metaprogramming
stuff (there's also one particular case I had to deal with around code
generation). That takes effort to migrate, but it's the long tail.

If you need to rewrite your code to enable the py3 transition, the issue isn't
python, it's your coding choices, and you should rewrite your code anyway.

~~~
jdormit
> If you need to rewrite your code to enable the py3 transition, the issue
> isn't python, it's your coding choices, and you should rewrite your code
> anyway.

I... don't even know what to make of this advice. Have you ever worked for an
engineering organization with more than 5 members? I can't just go to my boss
and say, "I need the next six months to rewrite our whole backend". I'd get
laughed out of the room.

Without a clear, business-first reason for an engineering project of that
magnitude, it's not ever going to be a priority or a realistic option.

~~~
joshuamorton
> I... don't even know what to make of this advice. Have you ever worked for
> an engineering organization with more than 5 members?

Yes.

> Without a clear, business-first reason for an engineering project of that
> magnitude, it's not ever going to be a priority or a realistic option.

I'm not suggesting that there is any realistic solution. I'm simply stating
that the cause of your pain isn't py2 to 3, but bad development practices that
existed independent of language or migration. These were going to cause you
pain at some point no matter what. It just happened that py3 was the forcing
function, as opposed to something else next year.

~~~
jdormit
While I won't deny that there were some unfortunate design decisions made in
the codebase (some _very_ questionable choices were made at some point), I
think that's inevitable in any codebase of a certain size and age that's been
worked on by enough people in a company that's changed substantially a number
of times.

But that's not the cause of my pain. Bad code can and will be written in Py2,
Py3, or any other language. The cause of my pain is that the language
developers chose to abandon work on the language that we use in favor of a
different language, one that is fundamentally different in some important
ways. As a result, the tooling and ecosystem on which we've built our product
is slowly stagnating and is getting close to being fully disfunctional.

~~~
joshuamorton
If you have bad code you'll eventually feel the cost of that bad code, if the
code lives for any significant length of time. Something will make you feel
that pain, either a new feature you need to develop or a change to the
ecosystem, or something else entirely.

If not py3, then something else. Specifically, the tooling ad ecosystem isn't
dysfunctional, you're just unable to maintain functionality among changing
requirements. "We must use py3 for our codebase" isn't particularly different
from "we must now support Japanese users" or "we need a new endpoint that
allows us to view data along a new axis". All 3 changes had the potential to
cause you developmental pain. You just hit one prior to the others.

------
musicale
"from python2 import {__some_old_feature__}" could go a long way toward easing
the transition.

Disclaimer: I spent a lot of time converting things from python2 to python3.
It's a big pain.

Pet peeve: don't break compatibility for ideological reasons. For example, the
print statement didn't need to die: it could have lived on as needed side-by-
side with the print() function.

~~~
chc
I don't get that pet peeve. There are aspects of converting Python 2 to Python
3 that can be hard, but print statements are really not one of them as far as
I've seen. Converting print statements to print function calls can be done
mechanically. I guess it's fair to say the print statement didn't need to die,
but it really didn't need to live either.

------
phendrenad2
I don't get this. Python is open-source. Surely _volunteer_ programmers don't
need the blessing of Guido to continue working on Python 2. And surely the
number of people who are still using Python 2 somehow indicates that there
will be some people among them capable of updating and maintaining Python 2. I
don't think time is "running out" at all, at least not in a sense that is
meaningful to people still using Python 2, after this many dire, repeated
warnings to switch now.

~~~
dagw
There are a couple of projects focusing on continuing development of python 2,
and possibly backporting python 3 feature where it makes sense.
[https://github.com/naftaliharris/tauthon](https://github.com/naftaliharris/tauthon)
seems to be the one with the most support.

The other problem is that it's not only your python version that won't see
official upgrades, but most of the libraries you use won't either. But I guess
if you're OK with Python 2 you're probably also OK with out of date versions
of django and numpy or whatever else you use.

But basically, anybody who hasn't at least started their python 3 port by now
have probably already weighed the pros and cons and decided that they're never
going to do it, and yelling at them isn't doing anybody any good

