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
