[Python-porting] futurize double testing ? nta

Dan MacNeil dan at omacneil.org
Sun Aug 4 19:17:15 EDT 2019


Absent unit tests, does using Futurize to require twice as much manual
testing (tests for both p2 and p3) as just converting to python 3 ?

How much kruft does Futurize leave in the python3 code , once you no longer
need python2 compatibility ?

Is Futurize as likely to generate "wrong" python2 code as 2to3 is to
generate "wrong" python 3 code?  (I am grateful for 2to3 , but it is only a
"mostly" solution.)

BACKGROUND

We're working on porting about 700 python files, most of which are plugins
for an internal application.

We've got the main part of the application (43 files) mostly ported to
python 3 via with 2to3 and various manual changes.

Our original thought  was to run futurize on the approximately 650 module
files maintained by people outside our group. In theory:

(1) They could test and then do their development work on the ported code
on our existing python2 application for a couple months and be ready for
our python 3 cut-over without too much trouble.

(2) We wouldn't have the danger of cutting everything over to python 3 all
at once.

Based on recent experience with 2to3 , I'm now guessing that getting things
to work on python2 in future mode is going to require roughly the same
amount of work as getting it to work in python 3 and instead of cutting
massive  changes over in the python3 change we'll do that in an earlier
python 2 change.

Thoughts ?
-- 
cell: 978-455-1885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-porting/attachments/20190804/58aaeb80/attachment.html>


More information about the Python-porting mailing list