On Fri, May 20, 2016 at 3:51 PM, Ondřej Čertík <[email protected]> wrote:
> Hi Aaron, > > My first suggestion would be to do whatever the other libraries agree > to do, based on https://python3statement.github.io/, i.e. we should > add SymPy there as well. > > My second suggestion is to be conservative, but if most libraries > agree to release Python 3 only version in 2019, then that's fine. > Since sympy is pure python and has no hard dependencies, I think it is a bit lower level than some of the libraries that have listed themselves on that statement. Given that, 2019 seems like a good amount of time for people to prepare and move their code that depends on sympy to more recent python versions. I don't think sympy should change that date just because other projects that are faster moving and exist higher up the technology stack decide to no longer support python2 sooner than sympy. > > For what is worth, I am still using Python 2.7 only. But I can > upgrade, I think most tools that I use support Python 3. > > What will be the lowest Python 3 version that we will support? > > Ondrej > > On Thu, May 19, 2016 at 9: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%3D6Kc4QmJ2zso4JfdwVyebxq4NMZWmNr%2BhRnvbGmfs6hT3Q%40mail.gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > 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/CADDwiVBM_QA9cdrvCkGsW8ebZQA3EAgm%3DQk0dWQ%2BGvxd%3Dp5v%2Bw%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAJXewOmD1Dbio9k2ZSGZwM3zUqXbgX31ZWS9ar2T1Og%2BRLY3fA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
