[Matplotlib-devel] supported python versions

[Benjamin Root]

Just realized something. Do you mean v2.0.1 or v2.1.0?

Also, what is the plan for v1.5.x? If we release a bugfix release of v2.0,
does that mean a bugfix release of v1.5 as well?

Ben Root
On Sep 26, 2015 5:29 PM, "Thomas Caswell" <tcaswell at gmail.com> wrote:

> 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
>>>
>>
> _______________________________________________
> 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/575dc07e/attachment-0001.html>