Comment 5 for bug 1756458

OK lets test that. Start by porting one of calibre's dependencies to python3. https://github.com/python-mechanize/mechanize
That one actually has good test coverage unlike large parts of calibre, which were written decades ago before unittesting was widespread, or that aren't suitable for unit testing. Lets see how it goes. It has no native code and I have already done lots of modernizing/pruning on its code base, so it should be ideal for 2to3. I'll be happy to create a 2to3 based branch for it. Just post on https://github.com/python-mechanize/mechanize/issues/9

And you are greatly underestimating the amount of work porting changes from python2 to python3 is. python3 is a fundamentally worse language than python2 for calibre's use case, which involves lots of dealing with bytes for binary file formats that calibre has to handle (the python3 bytes type is a travesty) and lots of interfacing with system APIs that use UTF-16 encoded data (on windows).

The difficulty of porting is not in the trivially automatable bits of the code base that 2to3 can handle. It comes from these things:

1) python3's awful bytes type
2) The necessity to keep converting strings to UTF-16 in the native code extensions that interface with system APIs on windows which is a huge performance sink and code bloat
3) The extremely high probability of introducing regressions for no real benefit.
4) The various performance regressions in python3 which there is no easy way to mitigate.
5) The large bits of legacy code in calibre that dont have unittests / aren't written in modern idioms.

As I have stated before, I am perfectly willing to keep maintaining python2 indefinitely, I already maintain a port of it that builds with VS2015. That is far less work and far less potential for bugs. That might change someday if one of calibre's python dependencies stops supporting python2 and it is complex enough that I dont feel comfortable maintaining it, but I doubt there are any such dependencies. Probably the two most complex are lxml and PyQt, both of which use code generators which means they are trivial to keep working with py2.