[Matplotlib-devel] supported python versions

OceanWolf juichenieder-nabb at yahoo.co.uk
Sun Sep 27 04:37:16 CEST 2015


For those wondering, I think it important to add that (afaik) 2.0 will 
follow very soon after 1.5, remember we only make an RC change(s) 
between 2.0 and 1.5...

On 27/09/15 04:29, Thomas Caswell wrote:
> I really meant v2.0.1 (as in the first micro / bug fix release for 2.0.
>
> I am hoping to not do 1.5.x bug fix releases unless someone asks for 
> them.  We historically have not done bug fixes on the previous 
> released version (ex, we did not do a 1.3.2 and will not do a 1.4.4).
>
> Tom
>
> On Sat, Sep 26, 2015 at 10:24 PM Benjamin Root <ben.v.root at gmail.com 
> <mailto:ben.v.root at gmail.com>> wrote:
>
>     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
>     <mailto: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 <mailto: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 <mailto: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
>                 <mailto:Matplotlib-devel at python.org>
>                 https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
>         _______________________________________________
>         Matplotlib-devel mailing list
>         Matplotlib-devel at python.org <mailto: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/20150927/17222f98/attachment-0001.html>


More information about the Matplotlib-devel mailing list