On 1 March 2014 13:09, ian o <ian.team.python@gmail.com> wrote:
And we don't actually mind all that much if applications don't migrate in the near term - Python 2 will have commercial support available well past 2020. (The developers of *those applications* might mind, though, just as anyone maintaining Python 2.4 compatibility for the benefit of RHEL/CentOS 5 typically isn't happy about it)
Your response is most dissapointing, and I would hope does not represent the community overall.
My apologies, I wrote my post assuming you had already read http://docs.python.org/dev/howto/pyporting.html and decided that the existing approaches described there weren't sufficient for your purposes. Those cases where the recommended migration process isn't considered acceptable for some reason (usually non-technical ones) are the cases that I consider to fall into the "it's OK to just keep using Python 2" category. However, I just realised two things: * that version of the guide is currently only in the Python 3.4 docs, and so the page at http://docs.python.org/3/howto/pyporting.html is still displaying the older 3.3 version of the guide (the page in the Python 2.7 docs is similarly outdated). * that guide is currently aimed primarily at library and framework authors, and doesn't explicitly discuss the migration of integrated applications. I have now filed http://bugs.python.org/issue20812 and http://bugs.python.org/issue20813 to address those limitations, but in the meantime, I will provide the missing information here: For developers of integrated applications that currently still have some dependencies on Python 2, the preferred migration path is to use tools like python-modernize or python-future to shift first into the large common subset of Python 2 and Python 3, and then only later switch fully to Python 3. This approach permits application developers to take the following path: 1. Python 2 only (status quo) 2. Python 2/3 compatible on Python 2 (waiting for dependencies) 3. Python 2/3 compatible on Python 3 (dependencies ported or replaced) 4. Python 3 only (drop Python 2 support) Brett Cannon's "caniusepython3" tool (https://pypi.python.org/pypi/caniusepython3/) is designed to automate the dependency analysis to see if all declared dependencies are Python 3 compatible (or have suitable alternatives available). However, if you're using system packages for dependency management, some data transformations will be needed to convert them to a form that the tool understands. My original reply assumed that you were already aware of the details of this preferred approach before posting your proposal, and I now realise that assumption was likely incorrect. Once again, my apologies. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia