Python 2 to 3 conversion - embrace the pain

[INADA Naoki]

google-api-client has ported from PY2 to PY2/3 recently.
https://github.com/google/google-api-python-client

It has 4000 lines of code and 3200 lines of tests.  It is legacy
library. It is indented by 2 spaces
since it was created before Google changes their coding style.

There are two major pull request: automatic change by modernize and
heuristic changes.
https://github.com/google/google-api-python-client/pull/62
https://github.com/google/google-api-python-client/pull/64

I feel this is reasonable effort, not bad.


Another experience is porting Flask application in my company from
Python 2 to Python 3.
It has 26k lines of code and 7.6k lines of tests.

Since we don't need to support both of PY2 and PY3, we used 2to3.
2to3 changes 740 lines. I had to replace google-api-client with
requests+oauthlib since
it had not supported PY3 yet.

After that, we encountered few trouble with untested code. But Porting
effort is surprisingly small.
We're happy now with Python 3.  We can write non-ascii string to log
without fear of UnicodeError.
We can use csv with unicode without hack.


Porting *modern* *application* code to *PY3 only* is easy, while
porting libraries on the edge of
bytes/unicode like google-api-client to PY2/3 is not easy.

I think application developers should use *only* Python 3 from this year.
If we start moving, more library developers will be able to start
writing Python 3 only code from next year.

On Mon, Mar 16, 2015 at 5:25 PM, Paul Rubin <no.email at nospam.invalid> wrote:
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>> It may, or may not, turn out that in hindsight there might have been better
>> ways to manage the Python2-3 transaction. Let's be honest, a lot of the
>> changes could have been introduced incrementally...
>
> Why did the changes have to be introduced at all?
>
>> I suspect that without the discipline and bloody-mindedness to just say NO
>> to requests to delay removal, Python would follow all those other languages
>> that have an ever-increasing pile of cruft that can never be removed because
>> it will break somebody's code. Design mistakes, obsolete features,
>> misspellings, "it's like that for historical reasons", and other nasties.
>
> The idea of "maturity" (an advertised feature of Python 2 back in the
> day) is that the pile of features is no longer growing so fast.  Right
> now I'm messing with some C code written in the 1980s and it still works
> fine.  I have a hard time imagining using Python 3 for anything.  Python
> 2 has its cruft but it's familiar and comfortable, and Python 3 gets
> minimal benefit for most of the breakage that it did (possible exception
> of the Unicode changes).  It still has most of the same mistakes and
> warts.  If I wanted to get away from those, I'd use Go or Ocaml or
> Erlang or Haskell or Javascript (possibly through a compiler like
> Purescript) or whatever.
>
> I'll see if I can remember what it was but I found some annoying
> incompatibility just a week or so ago that I don't think 2to3 would have
> caught, making me scared of Python 3 all over again.  I still think
> CPython should have stayed with Python 2 forever, and Python 3 should
> have been PyPy-based, letting PyPy drive its design, so that it could
> have introduced bigger changes with bigger benefits.  As we're seeing,
> even small incompatibilities and breakage cause big resistance, so if
> you're going to break stuff at all, you might as well go big.  Most old
> programs will never be ported either way.
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
INADA Naoki  <songofacandy at gmail.com>