[raylu]

That's quite a glorified view of tests. You can have the best test coverage in the world backed by a great CI culture but if porting something is a huge time investment, it may still be a huge time investment. Maybe there's one 2.x feature that you use almost everywhere that has been removed in 3.x and there's no simple way to replace it automatically.

[rogerbinns]

When I ported one of my projects to Python 3, by far the majority of time was spent on porting the test suite. The tests were written in Python 2 as well, and of course there is no tests of the test suite. It required extensive use of coverage to make sure that things were still being tested, plus new code to test things that lost coverage (eg items that were bytes). All of that effort then resulted in me being at the same place as I was with Python 2.

[stcredzero]

You can have the best test coverage in the world backed by a great CI culture but if porting something is a huge time investment, it may still be a huge time investment.

The right way to port is this: You make a rewriting engine that does the porting for you, and you develop on that, not on the port directly. The maintenance team keeps adding features to the legacy engine, but you can absorb those changes by running your rewriting engine on the whole code base.

Then, when the ported version is passing tests and looks good enough, you switch people over to the port. I've done this. It works. In fact, I know of at least one company that has based a consulting practice around this technique.

[lotyrin]

Yeah, but if you have a test suite you add Python 3 and silence the existing failures. Now you can (at least partially) avoid writing new code that wouldn't work on 3, as well as gain the option of refactoring things to resolve compatibility - with lots of freedom to decide how much effort to spend on that if any.

It'd no longer be a huge risky project where you have to cut the QA team over to Python 3, then spend a bunch of QA's time putting the new code through the ropes with no end in site while explaining to management that this is all providing zero new functionality.

[raylu]

Yeah, but if you have a test suite you add Python 3 and silence the existing failures.

They likely already know where a lot of their failures are going to be even without tests. The effort involved in fixing those known failures alone is prohibitive. The fact that the rest of regression testing will be easier with tests is nice, but doesn't reduce the work required to a level where they can justify doing it.

Now you can (at least partially) avoid writing new code that wouldn't work on 3,

Once you're on 3, you can just run your code and see if it works on 3. You don't need tests to avoid writing code that works on 2 but not 3.

as well as gain the option of refactoring things to resolve compatibility - with lots of freedom to decide how much effort to spend on that if any.

I don't think resolving compatibility issues is optional...

[lotyrin]

> I don't think resolving compatibility issues is optional...

It is if you stay on 2 for production/qa and the bulk of new feature development in the meantime. Only CI (and any developers working on python 3 compat.) would be running 3 and only to provide reports of how compatible things are.

Only once the test suite passes would you swap QA to 3, start removing 2 compatibility code (i.e. whatever you've done to hack around handling strings) and eventually ship 3 to production.

Edit: The solution of "just switch to 3 then make it work" is exactly what they can't do because of (completely valid) business and political concerns. I think that if they were able to have a goal of some small percent of test progress on Python 3 per release - but continue to ship features - they would be able to find time to do the work if it's at all a priority, even if it took many many releases. If it's not at all a priority then maybe that's the one-sentence summary instead.