In case it wasn't clear, I'd like to hear feedback from users of SymPy, as well as from developers.
Aaron Meurer On Thu, May 19, 2016 at 11:51 AM, Aaron Meurer <[email protected]> wrote: > 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 > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JKn_rcG7vKJTwnAqc5f%3Dt%3Dfdq5RD2TWu7kKcN9ssZjow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
