Hi Nathan, Thanks for sending this along. I think that 2019 is pretty reasonable. The only hard holdup for me on Py3 is hg, and it's looking more and more likely it'll be Py3 ready sooner than 2019. We should be thinking about signing such a statement, and personally 2019 would be fine with me. Python3 started out as a net loss in a lot of ways; speed, for instance, and the annoyances of bytes/strings. This has gotten better, to the point that it's become an attractive target. Async functiosn are neat, but not something we can probably use very much. But, type annotations are pretty awesome, and the improvement to the stdlib is also getting compelling. What does 2019 sound like to everyone else? I also don't think we should be maintaining a backport branch, since we have reasonably limited resources. -Matt On Thu, May 19, 2016 at 11:10 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Since we directly depend on sympy at a low level, this is something we need to think about dealing with.
---------- Forwarded message ---------- From: Aaron Meurer <asmeurer@gmail.com> Date: Thu, May 19, 2016 at 10:51 AM Subject: [sympy] Feedback requested: The future of Python 2.7 support in SymPy To: "sympy@googlegroups.com" <sympy@googlegroups.com>
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 sympy+unsubscribe@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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%3D6Kc4QmJ2zso4JfdwVyebxq4NMZWm.... For more options, visit https://groups.google.com/d/optout.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org