[Matplotlib-devel] supported python versions

[Thomas Caswell]

Having not heard anything back, I am going to take that as agreement :)

The plan will be:

   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

The mechanics of this will be after 2.0:
   - we reduce the travis test matrix to just 2.7, 3.4, 3.5,
   - any syntax related bug reports (mostly set literal and ordereddict)
are closed as not supported
   - review and merge 2.6/3.3 specific patches

Tom

On Tue, Sep 15, 2015 at 9:20 AM Thomas Caswell <tcaswell at gmail.com> 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).
>
> 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/20150926/d1e3d1b2/attachment.html>