My rationale for 2019: - Other projects are doing it sooner. For instance IPython in 2017. But they are also doing maintenance releases of older versions. We won't be doing that.
- The whole thing is based on the policy to support Python versions up until they cease being supported by core Python (i.e., no more security fixes). This is what we have done so far, e.g., for Python 2.5, 2.6, and 3.2. For those two, we were actually late, because of our slow release schedule. But 2.7 is so special, and given this effort, I think it makes sense to do it in 2019, instead of 2020, after the support is dropped. - Here is the end-of-life release schedule for the current versions of Python https://docs.python.org/devguide/#status-of-python-branches. Based on that, 3.4 is EoL on May 16, 2019. So if we release before then, we should support 3.4 in that release. Keep in mind that by that point there will probably be 3.6 and 3.7, maybe even 3.8. I wrote a blog post about this by the way https://asmeurer.github.io/blog/posts/moving-away-from-python-2/ Aaron Meurer On Fri, May 20, 2016 at 4:54 PM, Nathan Goldbaum <[email protected]> wrote: > > > 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. -- 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%3D6JicH8Gx0v7kJ_QWMB1dc%2BDNZPo9QCwffjJi4bA08j-%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
