[yt-dev] Fwd: [sympy] Feedback requested: The future of Python 2.7 support in SymPy

Matthew Turk matthewturk at gmail.com
Thu May 19 09:14:44 PDT 2016


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 at 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 at 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 at googlegroups.com" <sympy at 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 at googlegroups.com.
> To post to this group, send email to sympy at 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%3D6Kc4QmJ2zso4JfdwVyebxq4NMZWmNr%2BhRnvbGmfs6hT3Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list