[Matplotlib-devel] supported python versions

[Daniele Nicolodi]

On 15/09/15 15:20, Thomas Caswell wrote:
> 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).

I think this is a horrible idea. What is the difference between
supported and "known to work with"? For a given release to be known to
work with a give python release, it must be tested with that python
release. And it must be fixed if those tests break. Otherwise, what you
have is a release that "may work with" a given python release, but this
is not very useful to advertise.

I'm not saying that we should keep supporting python 2.6, but
introducing the concept of "known to work with" as opposed to "supported
to work with" is in my opinion a mistake.

Dropping support for old python versions is good, but please do that in
mayor releases and not in patch level releases. Breaking compatibility
in patch level releases is going to cause a lot of troubles to people
that need to support those old python releases.

> 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).

While I agree that those are useful features for the matplotlib API,
introducing those only for a few functions (as most of the matplotlib
API is constituted by functions imported from the same module) is going
to introduce inconsistencies (in an already quite messy API) that would
be hard to document, making the library even harder to use.


Cheers,
Daniele