At work, we have much smaller codebases that have fractional FTEs allocated to their ongoing maintenance. In spite of the difference in scale, my experience is

At work, we have much smaller codebases that have fractional FTEs allocated to their ongoing maintenance. In spite of the difference in scale, my experience is similar to what was described in the article. Because we had focused on getting the unicode to work right in those old code bases, we had good test coverage for those features as a result. The other common legacy problems to address were: - Other implicit encode/decode behaviors in py2 that need to be explicit in py3 - Old 'print' and 'except' statements not valid in py3, easily rewritten - Implicitly relative 'import' statements not valid in py3, rewritten with a little care - Arithmetic needing a change to the '//' operator for integer division - Waiting for py3 support in all third-party dependencies - Dealing with restructuring in standard lib packages and in upgraded third-party libs w/ py3 support As I reviewed the techniques for straddling py2 and py3, I was displeased with how many seemed to involve a third dialect which was not really idiomatic py2 nor py3, particularly for the unicode/bytes handling. Many third-party libraries and frameworks also made different choices for how they handled this. Trying to integrate those approaches looked to produce even uglier code. Also, some of our code had evolved since the Python 2.2 days and had accumulated cruft to import and wrap multiple generations of older standard lib and add-on packages which we have not cared about for 5+ years. The additional package restructuring in py3 would have made this even more bizarre. I wanted to see the code reset to use standard libs where possible and cull these legacy third-party dependencies. I also wanted the code to become more idiomatically py3, so whoever visited it for future maintenance would not need to work so hard to understand it. So, we chose a clean break where we finally clean up and modernize the code to py3-only without the added burden of supporting py2 deployments from the same code. The declared 2020 deadline helped this decision. We branched our repos and worked on py3 ports and integration testing in parallel while continuing to run py2 in production. We declared a feature freeze on the py2 code, so we would not have a merging nightmare later, and so that we could use that as pressure to prevent procrastination on scheduling the flag day where we merge PRs and convert all our repos to a py3-only worldview.