[Matplotlib-devel] supported python versions

[Thomas Caswell]

Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this as
orthogonal to the 'style only' marketing of 2.0.  The idea is that 2.0 will
still work with 2.6, but we are not committing to the bug-fix releases
working with 2.6.  The alternative to dropping py2.6 for 2.0 is dropping it
for 1.5 and in that, we might as well drop 3.3 for 1.5 as well.  My only
hesitation is the lead time and that 1.5 will work with 2.6 and 3.3.  How
about this instead:

  v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and
3.3
  v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6, and
3.3
  v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3

and when we break something in the 'known to work with' section we just
remove it from the listing in the next release (even a micro).

Daniele: The plan for python3 only code is to make a new module(s).  I
think we can be careful about which way dependencies go and only have to
have conditional imports in `pyplot`, if at all. The features I am most
excited about are keyword-only args (which will help make our APIs which
have a tremendous number of pass through kwargs easier to work
with/document) and the signature rewriting (which allows for higher-order
functions to propagate signatures).  No functionality is lost in python2
and if you are using python3 you get the new features (by importing the new
modules).  If users are committed to python2 support then obviously they do
not get to use the new features (ex other libraries), but in my from my
personal experience a vast majority of the code I write that uses mpl (that
is not in mpl core) is small standalone scripts or at the repl.  As more
people switch to python3 as their daily driver the number of 'python 3 only
projects', very broadly scoped, is going to sky rocket so I think in a year
this will be not be a big deal.

Ryan: enum and single-dispatch are the most compelling 3.4+ only feature
for us, but there are back-ported versions of both.  It also makes all of
our supported python3 versions in the random dict-iteration camp.  I am
tempted to suggest we only support 3.5 to get the infix mul operator and
then generalized unpacking syntax! (2.7, 3.5 woul

To be clear, what I mean by 'supported versions of python' is that if a
user reports a bug specific to an older version of python the mpl
developers should not feel guilty about not fixing it, but we will consider
reasonable patches which fix it.

Again, if 2.6 support is critical for anyone, please reach out, we would
love to work with you.

Tom

On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi <daniele at grinta.net> wrote:

> Hello,
>
> On 14/09/15 21:49, Thomas Caswell wrote:
> > I would like to propose the following for which version of python mpl
> > officially supports:
> >
> >  - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5
> >  - for v2.0 forward we support (2.7, 3.4, 3.5)
> >
> > and allow for new, python3 only, features to be developed for mpl2.1
> > onward, so long as they do not break any existing functionality in py2.7.
>
> I agree that dropping support for python 2.6 may be a good idea if there
> are real advantages in doing so, but maybe not in release 2.0 that was
> advertised to be only about style changes.
>
> However, I do not see how it may be possible to have python3 only
> features added in the code-base, without cluttering it with a lot of
> conditionals imports and versions checks. What are exactly the python3
> features you thing may easy the implementation of matplotlib features?
> How do you plan to make python3 only code coexist with the existing
> pythin2/3 code?
>
> Cheers,
> Daniele
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150915/79f3ce57/attachment-0001.html>