2016-06-10 2:24 GMT+02:00, Nick Coghlan <ncoghlan@gmail.com>:
Right, but there's also a time related aspect to this advice: most folks enthusiastic enough about Python 3 to adopt those kinds of invasive measures already support it, and Python 2.4 is now several years older than it was when folks first started adding Python 3 support to their projects (even RHEL 5 is reaching the point where Red Hat starts requiring the Extended Life Support addon for ongoing support beyond March 2017).
If I am not wrong then RHEL5 is stil about 2.4. 2016-06-10 0:20 GMT+02:00, Nick Coghlan <ncoghlan@gmail.com>:
Unfortunately, the only practical solution we've found for that case is to fork the code base until the maintainers of the original project are willing to raise the minimum version requirement to Python 2.6: http://portingguide.readthedocs.io/en/latest/process.html#drop-python-2-5-an...
If you need support 2.4 it is highly probably because very conservative customer or environement. Conservative environment could not approve to raise higher version. :/
While it's theoretically possible to support 2.4+ and 3.x in the same code base, it's painful in practice due to the lack of the forward compatibility features added in Python 2.6 (such as the Python 3 style syntax for name binding in except clauses)
It is why I like to see some guidlines how to do it. One practical possibility is (sorry for blasphemy) to (temporary!) drop support for python3. We need to understand that it is not only "fight" for python3 but also "fight" for python at all. So people who "want" to write code in 2.4 are not enemies. --- Btw. six library (now in version 1.10) dropped support for python 2.4 in version 1.5. and I am surprised. (They/we had probably to rename it to seven_and_half too :) Interesting for me is reason why they/we did it -> "Removed support for Python 2.4. This is because py.test no longer supports 2.4."