Issues
- Even if we stick with a minimum 2.x version of 2.7 (where the most compatibility aids have been added) there are still some things that can not be done when sharing the code because they will be syntax errors in one or the other flavor of Python. Since syntax is verified before the code in a module even starts executing then a syntax error will derail the import before we even have a chance to do anything about it. For example, using the u prefix on string constants (such as u"some text") is a syntax error in Python 3.2. So trying to keep both the python2- and the python3-compatible code in the same file will be tricky because in cases like that just doing conditionals is not enough.
- Duplicating and maintaining 2 sets of all the lib modules will be a major hassle too. It will take twice the work to fix a bug or add an enhancement, and there is the risk that if updating the copy is not done for some issue that the functionality could start to diverge.
Ideas
- Maintain the modules for Python2 but write the code such that the 2to3 tool (plus perhaps some extra scripts of our own) will produce code for Python3 without needing any help from a human, and then automatically run those tools as needed to produce the Python3 version of the code. This has some advantages in that there will still be only one master copy of the code that needs to be maintained, but some disadvantages as well in that the conversion tools need to be rock-solid and be trusted to not produce bugs of their own in the code they produce.
My other idea is sort of a hybrid approach where those modules that can be implemented for both Python2 and Python3 without many hassles and/or many conditionals checking the Python version are implemented as a single module. Other modules will have 2 implementations, each with the Python version embedded in the file name somehow, for example foomodule-py2.py and foomodule-py3.py. Then an import hook can be written and used that will watch for imports inside the wx package and will check first for the file name with verisoning in the name and will load that one if it is present, and will otherwise fall back to the normally named module if not. There may be some cases where a bit of refactoring will allow us to keep most of the code in a single non-versioned file and just move a few things out to a helper module that has -py2 and -py3 versions. For example foomodule.py, _foo_helper-py2.py and _foo_helper-py3.py.
- Maintain the py3 version of the library modules in a revision control branch and merge from the py2 version as needed for updates. Use the version control commands to check out the proper flavor of the library modules as needed to switch back and forth or when making distributions.
If anybody has any other ideas or examples of how other projects have handled this please insert a short note about it here.