What is a good way to support Python 2 in a Python 3 codebase when using PyPi?

Question

I've written a library in Python 3 and recently a pull request came in that added support for Python 2.7. The pull request is this: https://github.com/JelteF/PyLaTeX/pull/9.

What it basically does is adding some import fixs and making the super calls explicit. I have mixed feelings about this, since one of the big reasons I chose for python 3 was the cleaner syntax and this makes it compatible by using the 'ugly' syntax. However, I do like that people stuck with Python 2 can use the library as well.

This is why I was thinking about separate codebases for python2 and python3. Is there a way to set PyPi up so that it uses a separate codebase different versions of Python? Using separate branches would be preferable, since merging new changes would be easy in that case.

Or is there some better option that I'm overlooking?

Answer 1

I would not invest too much effort in supporting Python 2 in a Python 3 codebase. You're already running the "modern" way - adding more complexity to your project to support those who aren't upgrading should be low on your priorities.

Many projects written in Python 2 have been modified to run in Python 3 environments using the 2to3 tool, however this is a band-aid fix for those projects that are particularly concerned with backwards compatibility between major language versions. These projects are working in a worst-of-both-worlds environment - they have to program in Python 2, but ensure their changes remain compatible with Python 3. The better practice, where possible, is to simply release all future updates in Python 3.

In your case, you're starting with Python 3, and debating supporting Python 2's dated semantics. This should be a no-brainer, unless you really, really care about Python 2 users. Even if you can get everything working with the 3to2 tool like you suggest, and even if you can trust you're not introducing semantic issues*, you'll now be on the hook to continue supporting and testing this going forward, and you'll be limited to improvements that remain backwards compatible to Python 2. You have much better things to do with your time - like improving your library - than supporting such issues.

Instead I would suggest you reject this pull request, and encourage the submitter to release his own clone. This compartmentalizes your project from the Python 2 requirement, leaving you free to work on your project as you need, and letting the requester, who actually cares about this requirement, support and maintain it as they see fit.

*_{You claim "this library doesn't really use unicode and probably never will" - this is a dangerous way of thinking. Regardless of the use-case, a lack of proper unicode support will come back to haunt you later. Do it right the first time, and assume that failing to handle unicode will introduce unforeseen problems down the road - because it absolutely will.}

Answer 2

The simplest way to support Python 2 and Python 3 in the same code base is to use the six module to bridge the differences. It's still a significant undertaking though, there are semantic differences between the two languages, especially if you do text handling.