Hi all.
Some of us in the broader scientific Python community have been discussing the future of Python 2 support for various libraries. As you may know, Python 2.7 will cease to be supported by the core Python development team in 2020, meaning all updates to it will cease, including security updates. However, even though we are six major versions into Python 3, the larger community as a whole is still slow on uptake for supporting it.
The proposal is for libraries to let the community know now when they plan to drop Python 2.7 support, so that they will better prepared for it, and hopefully so as an encouragement to start transitioning now, if they haven't already.
I propose that we put it on our roadmap to drop Python 2.7 support in 2019. That is, the first release we do in 2019 will be the last to support Python 2.7. This is consistent with what we've done so far, which is to drop support for Python versions once they cease being supported by core Python.
Other libraries, such as IPython and likely matplotlib, are also joining together to sign a formal statement about this, which is drafted at
https://python3statement.github.io/.
Some libraries, such as IPython and matplotlib, are proposing to support a patchfix branch for an older version that supports Python 2.7, but I am opposed to any plan for SymPy that means supporting more than one version at a time, as I don't think we have the development effort for it.
I would like to hear feedback on this, both positive and negative. It isn't an official decision yet, until the community agrees on it.
Here is my rationale for doing this. I also plan to publish a blog post about this soon, which goes into more detail:
As you also probably know, SymPy, like other Python libraries, has done extra work to support Python 2 and 3 in the same codebase. While this work is easier than it used to be, it does put a maintainence burden on SymPy, and it prevents us from using language features which are Python 3-only. One language feature in particular that I would love to be able to use in SymPy is keyword-only arguments. This lets you write, for instance
def function(x, y, *, flag=False):
...
and then function(x, y, True) is a TypeError. Only function(x, y, flag=True) will work. This future-proofs the API, e.g., you can easily change it to function(x, y, z, *, flag=False) without any API breaks, and it forces explicitness in keyword arguments. That's one example. There are other Python 3-only features that we may or may not be able to make use of as well (like function annotations).
And even without that, the maintenance burden of supporting both versions is nontrivial. It means all developers have to know about the quirks of Python 2 and 3, regardless of which one they use primarily. It means that we always have to remember to add all the right compatibility imports at the top of files, and avoid things which are one version-only. And it means extra builds in the test matrix.
Aaron Meurer