Post Syndicated from original https://lwn.net/Articles/864938/rss

On his blog, Colin Watson has a lengthy reflection on moving the code for Ubuntu’s Launchpad software-collaboration web application from Python 2 to Python 3. He looks at some of the problem areas for upgrading, both in general and for Launchpad specifically, some pain points that were encountered, lessons learned, and the nine known regressions that reached the Launchpad production code during the process.

I’m not going to defend the Python 3 migration process; it was pretty rough in a lot of ways. Nor am I going to spend much effort relitigating it here, as it’s already been done to death elsewhere, and as I understand it the core Python developers have got the message loud and clear by now. At a bare minimum, a lot of valuable time was lost early in Python 3’s lifetime hanging on to flag-day-type porting strategies that were impractical for large projects, when it should have been providing for “bilingual” strategies (code that runs in both Python 2 and 3 for a transitional period) which is where most libraries and most large migrations ended up in practice. For instance, the early advice to library maintainers to maintain two parallel versions or perhaps translate dynamically with 2to3 was entirely impractical in most non-trivial cases and wasn’t what most people ended up doing, and yet the idea that 2to3 is all you need still floats around Stack Overflow and the like as a result. (These days, I would probably point people towards something more like Eevee’s porting FAQ as somewhere to start.)