[Matplotlib-devel] supported python versions

Thu Oct 8 16:21:46 EDT 2015

It may sound stupid.

If I introduce an OrderedDict to replace an ugly list of lists in
ToolManager (change that I wanted to do for a long time)

The problem will be automatically solved. No more 2.6 that's it that's all
On 8 Oct 2015 4:16 pm, "Nathan Goldbaum" <nathan12343 at gmail.com> wrote:

> Sorry to jump into this discussion, but why not just drop support for
> 2.6 completely in 1.5? Sure, it may work, but you're not committed to
> backporting bugfixes so it likely won't continue to work.
>
> Also, dropping support may bring some CentOS users out of the woodwork to
> beg for 2.6 support post-release...
>
> On Thursday, October 8, 2015, Thomas Caswell <tcaswell at gmail.com> wrote:
>
>> Sigh, all of my attempts to do this gracefully are failing :(
>>
>> On Thu, Oct 8, 2015 at 3:57 PM Nathaniel Smith <njs at pobox.com> wrote:
>>
>>> FWIW (which may not be much, none of this probably matters terribly
>>> :-)), if I saw py26 wheels on pypi or "Python :: 2 :: 2.6" in the trove
>>> classifiers, then I'd assume without thinking about it that this meant that
>>> 2.6 was supported.
>>> On Oct 8, 2015 12:53, "Thomas Caswell" <tcaswell at gmail.com> wrote:
>>>
>>>> I did not include D because, baring someone making a hard commitment to
>>>> maintain a 2.6 compatible 2.0.x bug-fix branches, it is not an option.
>>>>
>>>> One of the major planned features for 2.1 is serialization which is
>>>> being built on top of traitlets, which does not support py2.6.  I have an
>>>> open PR to drop [1] travis testing for 2.6/3.3 and master will lose 2.6
>>>> support (probably) within the month.
>>>>
>>>> After a bit more thinking, I think the right way to communicate the
>>>> distinction between 'works' and 'supported' is to only list the supported
>>>> versions (as in, we are committing to fixing it if mpl breaks on this
>>>> version of python) the website, but code the pypi packages for all versions
>>>> where it will run.  Dropping support for old version of python will be
>>>> noted there and in the release notes, but not mentioned anywhere else.
>>>>
>>>> So where I currently sit:
>>>>
>>>>  - 1.5 onward; supports 2.7, 3.4, 3.5
>>>>  - individual releases will be coded for what versions of python they
>>>> _run_ on
>>>>
>>>> And again, if 2.6 support is critical to anyone, let us know and we
>>>> will see what we can do.
>>>>
>>>> Tom
>>>>
>>>> [1] https://github.com/matplotlib/matplotlib/pull/5215
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 28, 2015 at 9:29 AM Benjamin Root <ben.v.root at gmail.com>
>>>> wrote:
>>>>
>>>>> I am for either C or D. It makes zero sense to me to drop 2.6/3.3 on a
>>>>> bugfix release, which is why I thought that v2.0.1 was a typo earlier.
>>>>>
>>>>> Ben Root
>>>>>
>>>>> On Mon, Sep 28, 2015 at 7:58 AM, Thomas Robitaille <
>>>>> thomas.robitaille at gmail.com> wrote:
>>>>>
>>>>>> If Python 2.6 and 3.3 support is completely dropped in Matplotlib 1.5
>>>>>> and 2.0, I don't think you will hear (m)any complaints from users.
>>>>>> When
>>>>>> I did a survey earlier this year, only 2% of users were on Python 2.6
>>>>>> and 1% on 3.3:
>>>>>>
>>>>>> http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/
>>>>>>
>>>>>> From an external point of view (since I am not a Matplotlib core dev),
>>>>>> I personally think option C makes more sense, i.e. still officially
>>>>>> supporting 2.6 and 3.3 in 1.5 (all the hard work is done) and then
>>>>>> dropping support in 2.0.
>>>>>>
>>>>>> Cheers,
>>>>>> Tom
>>>>>>
>>>>>> Daniele Nicolodi wrote:
>>>>>> > On 27/09/15 21:49, Thomas Caswell wrote:
>>>>>> >> We already have this 'know to work with' vs 'supported'
>>>>>> distinction,
>>>>>> >> this is the current state of python 3.2 support.  We don't test on
>>>>>> it,
>>>>>> >> my response to 3.2 specific bugs is 'upgrade', but if we get
>>>>>> reasonable,
>>>>>> >> non-destructive patches they will get merged (which we have done,
>>>>>> around
>>>>>> >> the 1.4 release, after we dropped 3.2, we merged some patches
>>>>>> >> from Christoph Gohlke which fixed 3.2 on windows).
>>>>>> >>
>>>>>> >> The reality is that we should have had this discussion 6-12 months
>>>>>> ago
>>>>>> >> (sorry OceanWolf), instead of on the cusp of a release, and
>>>>>> currently
>>>>>> >> master (and hence both the 1.5.0 and 2.0 releases) _will_ work with
>>>>>> >> py2.6 and py3.3 because we are currently testing on them.  There is
>>>>>> >> consensus in the core developers that we will not support py2.6/3.3
>>>>>> >> going forward so the question is what to do about the upcoming
>>>>>> >> releases.
>>>>>> > I agree that this discussion would have been better when the 1.5
>>>>>> and 2.0
>>>>>> > releases were planned, but I don't see much of a problem in defining
>>>>>> > things now, as not disruptive changes have been made to the
>>>>>> codebase.
>>>>>> >
>>>>>> > I agree that dropping support for python 2.6 and 3.3 is the way to
>>>>>> go.
>>>>>> > What I'm objecting is the "labeling" you are suggesting both in the
>>>>>> > sense of the "supported" vs "known to work with" terminology and
>>>>>> with
>>>>>> > release numbers.
>>>>>> >
>>>>>> > As Nathaniel pointed out it does not make much sense to drop
>>>>>> support for
>>>>>> > python 2.6 and 3.3 in a micro/patch level release. I think it makes
>>>>>> much
>>>>>> > more sense to plan to have a 2.1 release after 2.0 in which new
>>>>>> features
>>>>>> > could be added and old python versions support removed. Then 2.0
>>>>>> becomes
>>>>>> > a bugfix only branch. I haven't looked at the code, but I believe
>>>>>> that
>>>>>> > the only difference between 1.5 and 2.0 are the style defaults, so,
>>>>>> if
>>>>>> > there is demand, I don't see a problem to also backport bugfixes to
>>>>>> the
>>>>>> > 1.5 branch and release 1.5 series bugfixes.
>>>>>> >
>>>>>> >>  The options are:
>>>>>> >>
>>>>>> >>  - do not document at all that as far as we know 1.5/2.0 will work
>>>>>> on on
>>>>>> >> py2.6
>>>>>> >>  - document that as far as we know mpl does work on py2.6, but are
>>>>>> >> making no commitment to make sure that stays true.
>>>>>> > There is another option:
>>>>>> >
>>>>>> >  - keep supporting python 2.6 and 3.3 on 1.5 and 2.0 and drop
>>>>>> support on
>>>>>> > 2.1 where new development that can benefit from new python features
>>>>>> > should happen
>>>>>> >
>>>>>> >> Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches
>>>>>> which
>>>>>> >> back ports bug fixes in a 2.6 compatibly that would be great,
>>>>>> otherwise
>>>>>> >> given the limited resources the project currently has, that is not
>>>>>> >> something we can.
>>>>>> > I can try to contribute a bit, but, as I was trying to explain
>>>>>> above,
>>>>>> > I'm not opposing to drop support for old python releases, but
>>>>>> merely to
>>>>>> > the labeling and wording.
>>>>>> >
>>>>>> >> I have already linked to this article is this thread, but once
>>>>>> more for
>>>>>> >> good measure:
>>>>>> >>
>>>>>> http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
>>>>>> > As the work to make 1.5 and 2.0 releases work with python 2.6 and
>>>>>> 3.3
>>>>>> > has already been done, I don't think this article is much relevant
>>>>>> to
>>>>>> > the discussion. I'm all in favor of not keeping python 2.6 support,
>>>>>> and
>>>>>> > I don't think that anyone that uses python 3 is stuck with an old
>>>>>> python
>>>>>> > 3.3. But given that we already have the support for those release,
>>>>>> > please keep it and drop it in a future release.
>>>>>> >
>>>>>> > Cheer,
>>>>>> > 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
> _______________________________________________
> 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/20151008/4b625413/attachment.html>