Backgrading? Nunh-unh!

Over the weekend I thought frequently about the idea of "back-grading" PPQT2 to run under Python 2.7. Finally, I decided not to do it.

First of all, there would be a tedious amount of clerical work. I'd have to insert a from __future__ import... statement in almost every module. Then I'd have to edit every single super() call to insert the classname and self parameters. (I pondered quite a while in the middle of the night last night, whether there was some way to create a global function super23() that, when called from inside some class method, could check whether it was in Python 2 or 3, and if 2, introspect its own parent classname, and dynamically make the Python 2-style call. Decided that if the Six compatibility module didn't offer something like that, it couldn't be easy to do.)

All that would be at least a couple day's work and for what? I would not want to keep the code in Python 2. I would not want to add fixes or enhancements to it, unless I simultaneously added them to the master branch. It would be work done for no benefit and for only a temporary use.

Then I thought of two more things with serious implications. The first was the SortedDict class, upon which several modules are heavily dependent. I make great use of the valuesView and keysView it supplies, and assume that these produce lightweight access paths to existing values, not massive duplications of the dictionary values and keys. It is not clear from the SortedContainers doc whether in Python 2, the "views" are even available, or whether they work as efficiently.

But the major issue is Unicode strings. All through PPQT2 I am freely interchanging strings between Qt and Python and assuming that, one, this is done with minimal overhead, just straight memory copy because the character encoding is almost the same in both universes, and two, doesn't need explicit encoding and decoding by me, again because they both just use Unicode.

That is not the case in Python 2, where even with "from __future__ import unicode_literals", I can't be positive that when I just access the entire content of a QPlainTextEdit using the toPlainText() method, that I'll get the exact contents, special characters and all. If it works at all, it has to entail an expensive conversion from UTF-16 to UTF-8. And when I take the user-entered Find text string and stuff it back into a document using a QTextCursor, how do I need to encode that, or do I?

I realized it had been a great stress relief in version 2 to just not worry about these things because Python 3 and Qt use virtually the same Unicode string contents. If I back-grade to Python 2, I could not be at all sure of identifying all the places where attention must be paid to these potential conversions. It would not be like doing a search for the next use of "super".

So, spending the time to try to make PPQT2 work under Python 2.7, only in order to be able to bundle it with PyInstaller's current Develop branch, is not a good idea.

But if not that, what? Well, I think what I need to do is to donate my efforts to getting PyInstaller fixed for Python 3. I'm putting out some email feelers to see if I can get anybody else to help in this effort. In the meantime I will continue working on enhancements to PPQT2.