From tcaswell at gmail.com  Sat Oct  3 01:04:14 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 02 Oct 2015 23:04:14 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
Message-ID: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>

Hey folks,

I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.  Hopefully
the new conda packages will be available on `-c conda-forge` within the
next day or so.

Please open any new PRs targetted for 1.5.0 against the v1.5.x branch and
remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x when you
merge them (or ping me to do it).

Feel free to begin merging new features into master again.

In addition to the normal release notes we should plan to also write
several blog posts for the numfocus blog.  I think it would be good to have
a post for at least each of
  - property cycling
  - labeled data plotting
  - auto-redraw
  - %matplotlib notebook
  - the new color maps
  - the style module + new style sheets

Any volunteers to write those?

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151002/632d9e9c/attachment.html>

From matthew.brett at gmail.com  Sat Oct  3 01:39:20 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 2 Oct 2015 16:39:20 -0700
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
Message-ID: <CAH6Pt5rdDOA2VXYTXpoWeoF4WiXMHbMTOmJmJXXUmHG71pLpTw@mail.gmail.com>

Hi,

On Fri, Oct 2, 2015 at 4:04 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> Hey folks,
>
> I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.  Hopefully
> the new conda packages will be available on `-c conda-forge` within the next
> day or so.

Wheels at http://wheels.scipy.org/

pip install --pre -f http://wheels.scipy.org matplotlib

Matthew

From tcaswell at gmail.com  Sat Oct  3 01:54:08 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 02 Oct 2015 23:54:08 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAH6Pt5rdDOA2VXYTXpoWeoF4WiXMHbMTOmJmJXXUmHG71pLpTw@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAH6Pt5rdDOA2VXYTXpoWeoF4WiXMHbMTOmJmJXXUmHG71pLpTw@mail.gmail.com>
Message-ID: <CAA48SF_QSAuysC_rH23TUmGMe=6JaKfa+133VrV0OPxbJctU5Q@mail.gmail.com>

Thanks Matthew!

Tom

On Fri, Oct 2, 2015 at 7:39 PM Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Fri, Oct 2, 2015 at 4:04 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> > Hey folks,
> >
> > I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
> Hopefully
> > the new conda packages will be available on `-c conda-forge` within the
> next
> > day or so.
>
> Wheels at http://wheels.scipy.org/
>
> pip install --pre -f http://wheels.scipy.org matplotlib
>
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151002/f9ce146d/attachment.html>

From morph at debian.org  Sun Oct  4 02:01:35 2015
From: morph at debian.org (Sandro Tosi)
Date: Sun, 4 Oct 2015 01:01:35 +0100
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
Message-ID: <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>

Hey! I'm working to get this into Debian, so I'd like to understand
how strong the dependency against cycler is: is there a way to opt-out
from it at the moment? We dont have it already available, and avoiding
that dependency will help us the mpl in Debian (which in turn will
help Debian migrate to python3.5)

Thanks!

On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell <tcaswell at gmail.com> wrote:
> Hey folks,
>
> I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.  Hopefully
> the new conda packages will be available on `-c conda-forge` within the next
> day or so.
>
> Please open any new PRs targetted for 1.5.0 against the v1.5.x branch and
> remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x when you
> merge them (or ping me to do it).
>
> Feel free to begin merging new features into master again.
>
> In addition to the normal release notes we should plan to also write several
> blog posts for the numfocus blog.  I think it would be good to have a post
> for at least each of
>   - property cycling
>   - labeled data plotting
>   - auto-redraw
>   - %matplotlib notebook
>   - the new color maps
>   - the style module + new style sheets
>
> Any volunteers to write those?
>
> Tom
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From tcaswell at gmail.com  Sun Oct  4 04:43:03 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sun, 04 Oct 2015 02:43:03 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
Message-ID: <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>

It is a hard dependency, but it is only a few hundred line python file.

If getting it in as a top-level debian package is not possible, it should
not be too hard to vendor it.

My preference would be if you could handle this as a debian-specific
vendoring, but if this is really a blocker for debian (at it's down-stream
ecosystem) we can work something out up upstream.

When we started working on cycler part of the discussion was to split it
off because down-stream packagers liked to split things up!

Tom

On Sat, Oct 3, 2015 at 8:02 PM Sandro Tosi <morph at debian.org> wrote:

> Hey! I'm working to get this into Debian, so I'd like to understand
> how strong the dependency against cycler is: is there a way to opt-out
> from it at the moment? We dont have it already available, and avoiding
> that dependency will help us the mpl in Debian (which in turn will
> help Debian migrate to python3.5)
>
> Thanks!
>
> On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
> > Hey folks,
> >
> > I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
> Hopefully
> > the new conda packages will be available on `-c conda-forge` within the
> next
> > day or so.
> >
> > Please open any new PRs targetted for 1.5.0 against the v1.5.x branch and
> > remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x when you
> > merge them (or ping me to do it).
> >
> > Feel free to begin merging new features into master again.
> >
> > In addition to the normal release notes we should plan to also write
> several
> > blog posts for the numfocus blog.  I think it would be good to have a
> post
> > for at least each of
> >   - property cycling
> >   - labeled data plotting
> >   - auto-redraw
> >   - %matplotlib notebook
> >   - the new color maps
> >   - the style module + new style sheets
> >
> > Any volunteers to write those?
> >
> > Tom
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
> >
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151004/3660954b/attachment.html>

From cgohlke at uci.edu  Sun Oct  4 04:48:22 2015
From: cgohlke at uci.edu (Christoph Gohlke)
Date: Sat, 3 Oct 2015 19:48:22 -0700
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
Message-ID: <56109376.40604@uci.edu>

On 10/2/2015 4:04 PM, Thomas Caswell wrote:
> Hey folks,
>
> I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
> Hopefully the new conda packages will be available on `-c conda-forge`
> within the next day or so.
>
> Please open any new PRs targetted for 1.5.0 against the v1.5.x branch
> and remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x
> when you merge them (or ping me to do it).
>
> Feel free to begin merging new features into master again.
>
> In addition to the normal release notes we should plan to also write
> several blog posts for the numfocus blog.  I think it would be good to
> have a post for at least each of
>    - property cycling
>    - labeled data plotting
>    - auto-redraw
>    - %matplotlib notebook
>    - the new color maps
>    - the style module + new style sheets
>
> Any volunteers to write those?
>
> Tom
>
>

Forgot to mention: Windows installers, wheels and the HTML help file are 
at 
<http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.5.0rc2/windows/>

Christoph

From juichenieder-nabb at yahoo.co.uk  Sun Oct  4 13:34:10 2015
From: juichenieder-nabb at yahoo.co.uk (OceanWolf)
Date: Sun, 04 Oct 2015 13:34:10 +0200
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
Message-ID: <56110EB2.7010506@yahoo.co.uk>

As a debian user myself I would not have thought it impossible, it just 
takes longer, new packages can take several months to enter into 
unstable, but once in the process goes relatively fast.

I speak here only as an observer of the process, I of course defer to 
Sandro for the details (p.s. congratulations for holding and getting 
1.4.x into jessie at the 11th hour).

On 04/10/15 04:43, Thomas Caswell wrote:
> It is a hard dependency, but it is only a few hundred line python file.
>
> If getting it in as a top-level debian package is not possible, it 
> should not be too hard to vendor it.
>
> My preference would be if you could handle this as a debian-specific 
> vendoring, but if this is really a blocker for debian (at it's 
> down-stream ecosystem) we can work something out up upstream.
>
> When we started working on cycler part of the discussion was to split 
> it off because down-stream packagers liked to split things up!
>
> Tom
>
> On Sat, Oct 3, 2015 at 8:02 PM Sandro Tosi <morph at debian.org 
> <mailto:morph at debian.org>> wrote:
>
>     Hey! I'm working to get this into Debian, so I'd like to understand
>     how strong the dependency against cycler is: is there a way to opt-out
>     from it at the moment? We dont have it already available, and avoiding
>     that dependency will help us the mpl in Debian (which in turn will
>     help Debian migrate to python3.5)
>
>     Thanks!
>
>     On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell
>     <tcaswell at gmail.com <mailto:tcaswell at gmail.com>> wrote:
>     > Hey folks,
>     >
>     > I have tagged v1.5.0rc2 and created a v1.5.x branch on
>     upstream.  Hopefully
>     > the new conda packages will be available on `-c conda-forge`
>     within the next
>     > day or so.
>     >
>     > Please open any new PRs targetted for 1.5.0 against the v1.5.x
>     branch and
>     > remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x
>     when you
>     > merge them (or ping me to do it).
>     >
>     > Feel free to begin merging new features into master again.
>     >
>     > In addition to the normal release notes we should plan to also
>     write several
>     > blog posts for the numfocus blog.  I think it would be good to
>     have a post
>     > for at least each of
>     >   - property cycling
>     >   - labeled data plotting
>     >   - auto-redraw
>     >   - %matplotlib notebook
>     >   - the new color maps
>     >   - the style module + new style sheets
>     >
>     > Any volunteers to write those?
>     >
>     > Tom
>     >
>     > _______________________________________________
>     > Matplotlib-devel mailing list
>     > Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     > https://mail.python.org/mailman/listinfo/matplotlib-devel
>     >
>
>
>
>     --
>     Sandro Tosi (aka morph, morpheus, matrixhasu)
>     My website: http://matrixhasu.altervista.org/
>     Me at Debian: http://wiki.debian.org/SandroTosi
>
>
>
> _______________________________________________
> 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/20151004/fde7eb34/attachment.html>

From morph at debian.org  Sun Oct  4 13:47:18 2015
From: morph at debian.org (Sandro Tosi)
Date: Sun, 4 Oct 2015 12:47:18 +0100
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
Message-ID: <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>

On Sun, Oct 4, 2015 at 3:43 AM, Thomas Caswell <tcaswell at gmail.com> wrote:
> It is a hard dependency, but it is only a few hundred line python file.

that's ok, I'll get it packaged and will ask to be fast tracked for acceptance.

> If getting it in as a top-level debian package is not possible, it should
> not be too hard to vendor it.
>
> My preference would be if you could handle this as a debian-specific
> vendoring, but if this is really a blocker for debian (at it's down-stream
> ecosystem) we can work something out up upstream.
>
> When we started working on cycler part of the discussion was to split it off
> because down-stream packagers liked to split things up!

hehe, yeah we usually do (even though it sometimes makes our own lives
harder ;) )

thanks for the quick reply!

>
> Tom
>
> On Sat, Oct 3, 2015 at 8:02 PM Sandro Tosi <morph at debian.org> wrote:
>>
>> Hey! I'm working to get this into Debian, so I'd like to understand
>> how strong the dependency against cycler is: is there a way to opt-out
>> from it at the moment? We dont have it already available, and avoiding
>> that dependency will help us the mpl in Debian (which in turn will
>> help Debian migrate to python3.5)
>>
>> Thanks!
>>
>> On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell <tcaswell at gmail.com>
>> wrote:
>> > Hey folks,
>> >
>> > I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
>> > Hopefully
>> > the new conda packages will be available on `-c conda-forge` within the
>> > next
>> > day or so.
>> >
>> > Please open any new PRs targetted for 1.5.0 against the v1.5.x branch
>> > and
>> > remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x when
>> > you
>> > merge them (or ping me to do it).
>> >
>> > Feel free to begin merging new features into master again.
>> >
>> > In addition to the normal release notes we should plan to also write
>> > several
>> > blog posts for the numfocus blog.  I think it would be good to have a
>> > post
>> > for at least each of
>> >   - property cycling
>> >   - labeled data plotting
>> >   - auto-redraw
>> >   - %matplotlib notebook
>> >   - the new color maps
>> >   - the style module + new style sheets
>> >
>> > Any volunteers to write those?
>> >
>> > Tom
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel at python.org
>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>> >
>>
>>
>>
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From tcaswell at gmail.com  Sun Oct  4 21:51:00 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sun, 04 Oct 2015 19:51:00 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
Message-ID: <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>

The first one is that one of our tests reaches out to the internet for a
test.  We had a rough idea that this was not acceptable for debian, but
were not sure.  That test probably just needs to be wrapped in a know fail
if the internet is not accessible.

The second one is a bug that I put in just before the RC2, sorry.

`_path` is one of the c-extensions we build, there should be a `_path.so.*`
in the top-level mpl folder.

Tom

On Sun, Oct 4, 2015 at 3:43 PM Sandro Tosi <morph at debian.org> wrote:

> Ok, i managed to reach the point where I can build mpl on debian, but
> I'm getting some weird unittest failures (cut&paste will suck, so I'm
> also attaching the full build log):
>
> ```
> ERROR: matplotlib.tests.test_style.test_use_url
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in
> runTest
>     self.test(*self.arg)
>   File
> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/tests/test_style.py",
> line 61, in test_use_url
>     with style.context('https://gist.github.com/adrn/6590261/raw'):
>   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
>     return self.gen.next()
>   File
> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/style/core.py",
> line 121, in context
>     use(style)
>   File
> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/style/core.py",
> line 90, in use
>     raise IOError(msg % style)
> IOError: 'https://gist.github.com/adrn/6590261/raw' not found in the
> style library and input is not a valid URL or path. See
> `style.available` for list of available styles.
> ```
>
> it seems the test is trying to reach a remote URL (and fails): in
> debian we dont allow package to reach the internet when building, any
> suggestions how to disable this test?
>
> ```
> ERROR: Failure: RuntimeError (PyQt{4,5} bindings found despite sip
> importing
> Please install PyQt4 or PyQt5, uninstall sip or explicitly set the
> pyside backend.)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 409, in
> loadTestsFromName
>     module = resolve_name(addr.module)
>   File "/usr/lib/python2.7/dist-packages/nose/util.py", line 312, in
> resolve_name
>     module = __import__('.'.join(parts_copy))
>   File
> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/tests/test_backend_qt4.py",
> line 19, in <module>
>     from matplotlib.backends.qt_compat import QtCore
>   File
> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/backends/qt_compat.py",
> line 144, in <module>
>     raise RuntimeError("PyQt{4,5} bindings found despite sip importing\n"
> RuntimeError: PyQt{4,5} bindings found despite sip importing
> Please install PyQt4 or PyQt5, uninstall sip or explicitly set the
> pyside backend.
> ```
>
> I'm not sure I understand what it's trying to say. there are indeed by
> Qt4 and Qt5 available as long as Sip (as it's a dependency of PyQt5),
> so what is the problem there? note it worked with 1.4.x with these
> packges set.
>
> ```
> ERROR: test suite for <class
> 'matplotlib.sphinxext.tests.test_tinypages.TestTinyPages'>
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 209, in run
>     self.setUp()
>   File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 292, in setUp
>     self.setupContext(ancestor)
>   File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 315, in
> setupContext
>     try_run(context, names)
>   File "/usr/lib/python2.7/dist-packages/nose/util.py", line 471, in
> try_run
>     return func()
>   File
> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7-pydebug/matplotlib/sphinxext/tests/test_tinypages.py",
> line 58, in setup_class
>     out, err))
> RuntimeError: sphinx-build failed with stdout:
> Running Sphinx v1.3.1
> making output directory...
>
> stderr:
>
> Extension error:
> Could not import extension matplotlib.sphinxext.plot_directive
> (exception: No module named _path)
> ```
>
> I dont know what this _path should be imported  from, as after
> grepping a bit I was not able to identify that.
>
> let me know if you want me to report them as bugs or this email is fine.
>
>
> On Sun, Oct 4, 2015 at 12:47 PM, Sandro Tosi <morph at debian.org> wrote:
> > On Sun, Oct 4, 2015 at 3:43 AM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
> >> It is a hard dependency, but it is only a few hundred line python file.
> >
> > that's ok, I'll get it packaged and will ask to be fast tracked for
> acceptance.
> >
> >> If getting it in as a top-level debian package is not possible, it
> should
> >> not be too hard to vendor it.
> >>
> >> My preference would be if you could handle this as a debian-specific
> >> vendoring, but if this is really a blocker for debian (at it's
> down-stream
> >> ecosystem) we can work something out up upstream.
> >>
> >> When we started working on cycler part of the discussion was to split
> it off
> >> because down-stream packagers liked to split things up!
> >
> > hehe, yeah we usually do (even though it sometimes makes our own lives
> > harder ;) )
> >
> > thanks for the quick reply!
> >
> >>
> >> Tom
> >>
> >> On Sat, Oct 3, 2015 at 8:02 PM Sandro Tosi <morph at debian.org> wrote:
> >>>
> >>> Hey! I'm working to get this into Debian, so I'd like to understand
> >>> how strong the dependency against cycler is: is there a way to opt-out
> >>> from it at the moment? We dont have it already available, and avoiding
> >>> that dependency will help us the mpl in Debian (which in turn will
> >>> help Debian migrate to python3.5)
> >>>
> >>> Thanks!
> >>>
> >>> On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell <tcaswell at gmail.com>
> >>> wrote:
> >>> > Hey folks,
> >>> >
> >>> > I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
> >>> > Hopefully
> >>> > the new conda packages will be available on `-c conda-forge` within
> the
> >>> > next
> >>> > day or so.
> >>> >
> >>> > Please open any new PRs targetted for 1.5.0 against the v1.5.x branch
> >>> > and
> >>> > remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x when
> >>> > you
> >>> > merge them (or ping me to do it).
> >>> >
> >>> > Feel free to begin merging new features into master again.
> >>> >
> >>> > In addition to the normal release notes we should plan to also write
> >>> > several
> >>> > blog posts for the numfocus blog.  I think it would be good to have a
> >>> > post
> >>> > for at least each of
> >>> >   - property cycling
> >>> >   - labeled data plotting
> >>> >   - auto-redraw
> >>> >   - %matplotlib notebook
> >>> >   - the new color maps
> >>> >   - the style module + new style sheets
> >>> >
> >>> > Any volunteers to write those?
> >>> >
> >>> > Tom
> >>> >
> >>> > _______________________________________________
> >>> > Matplotlib-devel mailing list
> >>> > Matplotlib-devel at python.org
> >>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Sandro Tosi (aka morph, morpheus, matrixhasu)
> >>> My website: http://matrixhasu.altervista.org/
> >>> Me at Debian: http://wiki.debian.org/SandroTosi
> >
> >
> >
> > --
> > Sandro Tosi (aka morph, morpheus, matrixhasu)
> > My website: http://matrixhasu.altervista.org/
> > Me at Debian: http://wiki.debian.org/SandroTosi
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151004/89653845/attachment-0001.html>

From tcaswell at gmail.com  Sun Oct  4 22:27:12 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sun, 04 Oct 2015 20:27:12 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
Message-ID: <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>

This PR should address the url issue:
https://github.com/matplotlib/matplotlib/pull/5188
This PR should address the qt issue:
https://github.com/matplotlib/matplotlib/pull/5187



On Sun, Oct 4, 2015 at 3:51 PM Thomas Caswell <tcaswell at gmail.com> wrote:

> The first one is that one of our tests reaches out to the internet for a
> test.  We had a rough idea that this was not acceptable for debian, but
> were not sure.  That test probably just needs to be wrapped in a know fail
> if the internet is not accessible.
>
> The second one is a bug that I put in just before the RC2, sorry.
>
> `_path` is one of the c-extensions we build, there should be a
> `_path.so.*` in the top-level mpl folder.
>
> Tom
>
> On Sun, Oct 4, 2015 at 3:43 PM Sandro Tosi <morph at debian.org> wrote:
>
>> Ok, i managed to reach the point where I can build mpl on debian, but
>> I'm getting some weird unittest failures (cut&paste will suck, so I'm
>> also attaching the full build log):
>>
>> ```
>> ERROR: matplotlib.tests.test_style.test_use_url
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in
>> runTest
>>     self.test(*self.arg)
>>   File
>> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/tests/test_style.py",
>> line 61, in test_use_url
>>     with style.context('https://gist.github.com/adrn/6590261/raw'):
>>   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
>>     return self.gen.next()
>>   File
>> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/style/core.py",
>> line 121, in context
>>     use(style)
>>   File
>> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/style/core.py",
>> line 90, in use
>>     raise IOError(msg % style)
>> IOError: 'https://gist.github.com/adrn/6590261/raw' not found in the
>> style library and input is not a valid URL or path. See
>> `style.available` for list of available styles.
>> ```
>>
>> it seems the test is trying to reach a remote URL (and fails): in
>> debian we dont allow package to reach the internet when building, any
>> suggestions how to disable this test?
>>
>> ```
>> ERROR: Failure: RuntimeError (PyQt{4,5} bindings found despite sip
>> importing
>> Please install PyQt4 or PyQt5, uninstall sip or explicitly set the
>> pyside backend.)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 409, in
>> loadTestsFromName
>>     module = resolve_name(addr.module)
>>   File "/usr/lib/python2.7/dist-packages/nose/util.py", line 312, in
>> resolve_name
>>     module = __import__('.'.join(parts_copy))
>>   File
>> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/tests/test_backend_qt4.py",
>> line 19, in <module>
>>     from matplotlib.backends.qt_compat import QtCore
>>   File
>> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/backends/qt_compat.py",
>> line 144, in <module>
>>     raise RuntimeError("PyQt{4,5} bindings found despite sip importing\n"
>> RuntimeError: PyQt{4,5} bindings found despite sip importing
>> Please install PyQt4 or PyQt5, uninstall sip or explicitly set the
>> pyside backend.
>> ```
>>
>> I'm not sure I understand what it's trying to say. there are indeed by
>> Qt4 and Qt5 available as long as Sip (as it's a dependency of PyQt5),
>> so what is the problem there? note it worked with 1.4.x with these
>> packges set.
>>
>> ```
>> ERROR: test suite for <class
>> 'matplotlib.sphinxext.tests.test_tinypages.TestTinyPages'>
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 209, in run
>>     self.setUp()
>>   File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 292, in
>> setUp
>>     self.setupContext(ancestor)
>>   File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 315, in
>> setupContext
>>     try_run(context, names)
>>   File "/usr/lib/python2.7/dist-packages/nose/util.py", line 471, in
>> try_run
>>     return func()
>>   File
>> "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7-pydebug/matplotlib/sphinxext/tests/test_tinypages.py",
>> line 58, in setup_class
>>     out, err))
>> RuntimeError: sphinx-build failed with stdout:
>> Running Sphinx v1.3.1
>> making output directory...
>>
>> stderr:
>>
>> Extension error:
>> Could not import extension matplotlib.sphinxext.plot_directive
>> (exception: No module named _path)
>> ```
>>
>> I dont know what this _path should be imported  from, as after
>> grepping a bit I was not able to identify that.
>>
>> let me know if you want me to report them as bugs or this email is fine.
>>
>>
>> On Sun, Oct 4, 2015 at 12:47 PM, Sandro Tosi <morph at debian.org> wrote:
>> > On Sun, Oct 4, 2015 at 3:43 AM, Thomas Caswell <tcaswell at gmail.com>
>> wrote:
>> >> It is a hard dependency, but it is only a few hundred line python file.
>> >
>> > that's ok, I'll get it packaged and will ask to be fast tracked for
>> acceptance.
>> >
>> >> If getting it in as a top-level debian package is not possible, it
>> should
>> >> not be too hard to vendor it.
>> >>
>> >> My preference would be if you could handle this as a debian-specific
>> >> vendoring, but if this is really a blocker for debian (at it's
>> down-stream
>> >> ecosystem) we can work something out up upstream.
>> >>
>> >> When we started working on cycler part of the discussion was to split
>> it off
>> >> because down-stream packagers liked to split things up!
>> >
>> > hehe, yeah we usually do (even though it sometimes makes our own lives
>> > harder ;) )
>> >
>> > thanks for the quick reply!
>> >
>> >>
>> >> Tom
>> >>
>> >> On Sat, Oct 3, 2015 at 8:02 PM Sandro Tosi <morph at debian.org> wrote:
>> >>>
>> >>> Hey! I'm working to get this into Debian, so I'd like to understand
>> >>> how strong the dependency against cycler is: is there a way to opt-out
>> >>> from it at the moment? We dont have it already available, and avoiding
>> >>> that dependency will help us the mpl in Debian (which in turn will
>> >>> help Debian migrate to python3.5)
>> >>>
>> >>> Thanks!
>> >>>
>> >>> On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell <tcaswell at gmail.com>
>> >>> wrote:
>> >>> > Hey folks,
>> >>> >
>> >>> > I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
>> >>> > Hopefully
>> >>> > the new conda packages will be available on `-c conda-forge` within
>> the
>> >>> > next
>> >>> > day or so.
>> >>> >
>> >>> > Please open any new PRs targetted for 1.5.0 against the v1.5.x
>> branch
>> >>> > and
>> >>> > remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x
>> when
>> >>> > you
>> >>> > merge them (or ping me to do it).
>> >>> >
>> >>> > Feel free to begin merging new features into master again.
>> >>> >
>> >>> > In addition to the normal release notes we should plan to also write
>> >>> > several
>> >>> > blog posts for the numfocus blog.  I think it would be good to have
>> a
>> >>> > post
>> >>> > for at least each of
>> >>> >   - property cycling
>> >>> >   - labeled data plotting
>> >>> >   - auto-redraw
>> >>> >   - %matplotlib notebook
>> >>> >   - the new color maps
>> >>> >   - the style module + new style sheets
>> >>> >
>> >>> > Any volunteers to write those?
>> >>> >
>> >>> > Tom
>> >>> >
>> >>> > _______________________________________________
>> >>> > Matplotlib-devel mailing list
>> >>> > Matplotlib-devel at python.org
>> >>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> >>> My website: http://matrixhasu.altervista.org/
>> >>> Me at Debian: http://wiki.debian.org/SandroTosi
>> >
>> >
>> >
>> > --
>> > Sandro Tosi (aka morph, morpheus, matrixhasu)
>> > My website: http://matrixhasu.altervista.org/
>> > Me at Debian: http://wiki.debian.org/SandroTosi
>>
>>
>>
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151004/3cd04bde/attachment.html>

From morph at debian.org  Sun Oct  4 22:41:37 2015
From: morph at debian.org (Sandro Tosi)
Date: Sun, 4 Oct 2015 21:41:37 +0100
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
 <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
Message-ID: <CAB4XWXx4Wg_PC4p3=QQPaXUsp4fK139+R4pqAKOC3MVZffp1XA@mail.gmail.com>

On Sun, Oct 4, 2015 at 9:27 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> On Sun, Oct 4, 2015 at 3:51 PM Thomas Caswell <tcaswell at gmail.com> wrote:
>>
>> The first one is that one of our tests reaches out to the internet for a
>> test.  We had a rough idea that this was not acceptable for debian, but were
>> not sure.  That test probably just needs to be wrapped in a know fail if the
>> internet is not accessible.

yeah I seem to remember there was a msg asking for my input on it and
I falied to reply, sorry about that

> This PR should address the url issue:
> https://github.com/matplotlib/matplotlib/pull/5188

geez you're too quick! what I wanted to say is that we dont want to
anything contacting the internet, not that we actively prevent it. The
error in this case is probably that HTTPS is not correctly recognized
as a URL as you might need to use an SSL handler.

what I have in mind is a way to mark those tests as accessing the
internet and skipping them when running the unittest (something like
I'm doing at http://anonscm.debian.org/cgit/reportbug/reportbug.git/tree/test/test_urlutils.py#n10
and http://anonscm.debian.org/cgit/reportbug/reportbug.git/tree/Makefile#n12
but I am using the nosetest runner there).

this is how I run tests for mpl in debian:

ln 39-56 of http://anonscm.debian.org/viewvc/python-modules/packages/matplotlib/trunk/debian/rules?revision=34251&view=markup

>> The second one is a bug that I put in just before the RC2, sorry.

> This PR should address the qt issue:
> https://github.com/matplotlib/matplotlib/pull/5187

will that this in a bit

>> `_path` is one of the c-extensions we build, there should be a
>> `_path.so.*` in the top-level mpl folder.

I see the python extensions build in matplotlib/_path.so but then it
is not installed right? then that's the problem, as I run setup.py
install in a temp dir and then set the PYTHONPATH to that dir to pick
up the module.

in the meantime a new error came up, while building latex doc:

```
Adding blank page after the table of contents.
[1] [2] [1] [2]
Chapter 1.
(/usr/share/texlive/texmf-dist/tex/latex/txfonts/t1txtt.fd)

! Package inputenc Error: Unicode char \u8:? not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...

l.163 Ste?
           fan van der Walt's talk from SciPy2015
?
! Emergency stop.
 ...

l.163 Ste?
           fan van der Walt's talk from SciPy2015
!  ==> Fatal error occurred, no output PDF file produced!
```

attached the Matplotlib.log file of the latex compiler

Thanks!

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Matplotlib.log.bz2
Type: application/x-bzip2
Size: 9346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151004/71d1b319/attachment-0001.bin>

From jks at iki.fi  Mon Oct  5 06:32:01 2015
From: jks at iki.fi (=?iso-8859-1?Q?Jouni_K=2E_Sepp=E4nen?=)
Date: Mon, 05 Oct 2015 07:32:01 +0300
Subject: [Matplotlib-devel] v1.5.0rc2
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
 <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
 <CAB4XWXx4Wg_PC4p3=QQPaXUsp4fK139+R4pqAKOC3MVZffp1XA@mail.gmail.com>
Message-ID: <m24mi6c4vy.fsf@jks.iki.fi>

Sandro Tosi <morph at debian.org> writes:

> in the meantime a new error came up, while building latex doc:
>
> ```
> Adding blank page after the table of contents.
> [1] [2] [1] [2]
> Chapter 1.
> (/usr/share/texlive/texmf-dist/tex/latex/txfonts/t1txtt.fd)
>
> ! Package inputenc Error: Unicode char \u8:? not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...
>
> l.163 Ste?
>            fan van der Walt's talk from SciPy2015

The letter ? in the source file is encoded using U+0301 COMBINING ACUTE
ACCENT (UTF-8 bytes cc 81):

$ git grep 'van der W' | hexdump -C
00000000  73 74 79 6c 65 5f 63 68  61 6e 67 65 73 2e 72 73  |style_changes.rs|
00000010  74 3a 53 74 65 cc 81 66  61 6e 20 76 61 6e 20 64  |t:Ste..fan van d|
00000020  65 72 20 57 61 6c 74 27  73 20 74 61 6c 6b 20 66  |er Walt's talk f|
00000030  72 6f 6d 20 53 63 69 50  79 32 30 31 35 0a        |rom SciPy2015.|
0000003e

LaTeX would probably understand U+00E9 LATIN SMALL LETTER E WITH ACUTE
better. I'll make a PR.

-- 
Jouni K. Sepp?nen
http://www.iki.fi/jks


From ben.v.root at gmail.com  Mon Oct  5 21:00:00 2015
From: ben.v.root at gmail.com (Benjamin Root)
Date: Mon, 5 Oct 2015 15:00:00 -0400
Subject: [Matplotlib-devel] Gauging interest in a AsynchronousAnimation
	class
In-Reply-To: <CALRw1GF0iJpEx18mvbVqYCCnTXvCEpm_LEzD6YpE-qr1jSEqVw@mail.gmail.com>
References: <CALRw1GF0iJpEx18mvbVqYCCnTXvCEpm_LEzD6YpE-qr1jSEqVw@mail.gmail.com>
Message-ID: <CANNq6Fnt-KUhO27x=ZKF_8ST3m8mWmgFKwjGZDg754jM-SC1Rw@mail.gmail.com>

Sorry we haven't gotten back to you sooner, we are currently focusing on
getting the long-awaited v1.5/v2.0 releases finalized.

I will admit that I have been absolutely hating the simple animation
examples that require using globals. And the prospect of decoupling the
animation & application code is attractive. I will point out that this code
wouldn't work for all artists (particularly 3D objects), but it is a good
first step, and would help give us a kick in the pants to normalize data
setting across all artists.

Cheers!
Ben Root


On Sat, Sep 19, 2015 at 3:47 PM, toemoss garcia <toemossgarcia at gmail.com>
wrote:

> Hi,
>
> Out of my own needs I developed an animation class that is very similar to
> FuncAnimation but is drawn asynchronously (not that this couldn't be done
> with FuncAnimation, this is just a more direct path). Instead of trying to
> explain the differences off the bat I'll give a base example usage
>
> fig, ax = plt.subplots()
> x = np.arange(0, 2*np.pi, 0.01)
> line, = ax.plot(x, np.sin(x))
>
> ani = AsyncAnimation(fig,interval=50)
> fig.show() # starts the first 'draw' without entering the mpl mainloop
>
> i = 0
> while ani.update(): #update() flushes the animation's queue
>     i += 1
>     y = np.sin(x+i/10.0)
>     ani.append_artist(line,(x,y))
>
> This is the simplest example, where one frame is queued at a time and
> `update()` blocks execution until that frame has been rendered (so this is
> effectively the same as a FuncAnimation).
>
> Aesthetically, the difference is that the animation code lives inside a
> loop instead of a function call. This removes the need to have the
> animation code pass variables back to the user or doing any global imports
> of variables which IMHO makes the application code cleaner and more
> self-contained. Personally, I find this a simpler and more intuitive way to
> write interactive animation applications. (Alternatively, writing
> application code inside of a class that uses FuncAnimation gives you
> similar benefits of cleaner code).
>
> The other more significant difference is that having rendering being done
> asynchronously basically decouples the animation code from the application
> code, which
>
>    1. Makes it trivial to execute the graphics rendering as a separate
>    process
>    2. Gives the user more flexibility in their application code (you
>    could imagine an application "queueing up" multiple frames at a time,
>    allowing them to render in their own time).
>
> Anyway, here is the code as it stands now (most important are the
> `append_artist` and `update` functions; the rest of the code is very
> similar to the FuncAnimation class):
>
> class AsyncAnimation(Animation):
>     """
>     Makes an animation by reading from a user filled queue every *interval*
>     milliseconds. User adds to the queue by calling *update_artists*.
>
>     Note that data is _not_ copied before being put into the queue; if a
> reference
>     is passed (such as a numpy ndarray) whatever data the reference is
> pointing
>     to at draw time will be plotted.
>
>     *init_func* is a function used to draw a clear frame. If not given, the
>     results of drawing from the first item in the frames sequence will be
>     used. This function will be called once before the first frame.
>
>     *event_source* Default event source to trigger poll of the artist
> queue. By
>     default this is a timer with an *interval* millisecond timeout.
>     """
>     def
> __init__(self,fig,init_func=None,event_source=None,interval=10,blit=True):
>         self._data = deque()
>         self._lag = 0
>         self._queued = False
>
>         self._fig = fig
>         self._interval = interval
>
>         self._init_func = init_func
>
>         if event_source is None:
>             event_source = fig.canvas.new_timer(interval=self._interval)
>
>         Animation.__init__(self,fig,event_source=event_source,blit=blit)
>
>     def new_frame_seq(self):
>         return itertools.count()
>
>     def _init_draw(self):
>         if self._init_func is not None:
>             self._drawn_artists = self._init_func()
>             for a in self._drawn_artists:
>                 a.set_animated(self._blit)
>
>     def _draw_next_frame(self, *args):
>         # carry on if there's nothing to draw right now
>         if self._data:
>             Animation._draw_next_frame(self,*args)
>
>     def _draw_frame(self,framedata):
>         artdata = self._data.popleft()
>
>         artists = []
>         for (a,d) in artdata:
>             artists.append(a)
>             if d is not None: a.set_data(d)
>             a.set_animated(self._blit)
>         self._drawn_artists = artists
>
>     def append_artist(self,artist,data=None):
>         self._queue_artists((artist,data),)
>
>     def extend_artists(self,artists):
>         self._queue_artists(*artists)
>
>     def _queue_artists(self,*artists):
>         if len(self._data) and self._queued:
>             self._data[-1] += artists
>             return
>
>         self._queued = True
>
>         if len(self._data) > self._lag:
>             warnings.warn("Artists queue is behind by %d" %
> len(self._data))
>             self._lag = len(self._data)
>
>         self._data.append(artists)
>
>     def update(self,block=True):
>         self._queued = False
>         self._fig.canvas.flush_events()
>
>         if block:
>             while len(self._data) and self.event_source is not None:
>                 self._fig.canvas.flush_events()
>
>         return self.event_source is not None
>
>
> So, I've developed this code enough that it fills my needs, but it needs
> some work to add in all the expected matplotlib functionality. Is something
> that would be useful to people?
>
>
> _______________________________________________
> 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/20151005/339ce946/attachment.html>

From morph at debian.org  Wed Oct  7 00:56:37 2015
From: morph at debian.org (Sandro Tosi)
Date: Tue, 6 Oct 2015 23:56:37 +0100
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <m24mi6c4vy.fsf@jks.iki.fi>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
 <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
 <CAB4XWXx4Wg_PC4p3=QQPaXUsp4fK139+R4pqAKOC3MVZffp1XA@mail.gmail.com>
 <m24mi6c4vy.fsf@jks.iki.fi>
Message-ID: <CAB4XWXwih_8-JhEjGH6-MXrTSkFchBefA0Y4gGvaqrQwuPw4DA@mail.gmail.com>

first of all, thanks a lot for the prompt support in making mpl ready
to be uploaded to Debian! which happened last night, and it is mostly
built on all our official architectures (except mips, it's taking its
time to be built there eheh), but there are some unittest failures,
how do you want me to report them: one issue per arcihtecture? all of
them together? something else? I expect most of them will be wontfix,
but some might uncover hidden bugs

On Mon, Oct 5, 2015 at 5:32 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:
> Sandro Tosi <morph at debian.org> writes:
>
>> in the meantime a new error came up, while building latex doc:
>>
>> ```
>> Adding blank page after the table of contents.
>> [1] [2] [1] [2]
>> Chapter 1.
>> (/usr/share/texlive/texmf-dist/tex/latex/txfonts/t1txtt.fd)
>>
>> ! Package inputenc Error: Unicode char \u8:? not set up for use with LaTeX.
>>
>> See the inputenc package documentation for explanation.
>> Type  H <return>  for immediate help.
>>  ...
>>
>> l.163 Ste?
>>            fan van der Walt's talk from SciPy2015
>
> The letter ? in the source file is encoded using U+0301 COMBINING ACUTE
> ACCENT (UTF-8 bytes cc 81):
>
> $ git grep 'van der W' | hexdump -C
> 00000000  73 74 79 6c 65 5f 63 68  61 6e 67 65 73 2e 72 73  |style_changes.rs|
> 00000010  74 3a 53 74 65 cc 81 66  61 6e 20 76 61 6e 20 64  |t:Ste..fan van d|
> 00000020  65 72 20 57 61 6c 74 27  73 20 74 61 6c 6b 20 66  |er Walt's talk f|
> 00000030  72 6f 6d 20 53 63 69 50  79 32 30 31 35 0a        |rom SciPy2015.|
> 0000003e
>
> LaTeX would probably understand U+00E9 LATIN SMALL LETTER E WITH ACUTE
> better. I'll make a PR.
>
> --
> Jouni K. Sepp?nen
> http://www.iki.fi/jks
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From tcaswell at gmail.com  Wed Oct  7 00:59:42 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 06 Oct 2015 22:59:42 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAB4XWXwih_8-JhEjGH6-MXrTSkFchBefA0Y4gGvaqrQwuPw4DA@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
 <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
 <CAB4XWXx4Wg_PC4p3=QQPaXUsp4fK139+R4pqAKOC3MVZffp1XA@mail.gmail.com>
 <m24mi6c4vy.fsf@jks.iki.fi>
 <CAB4XWXwih_8-JhEjGH6-MXrTSkFchBefA0Y4gGvaqrQwuPw4DA@mail.gmail.com>
Message-ID: <CAA48SF-9mtjYJkcOTpQ+v8QUL7gxuX79uG0V9FgihuqTTf+B6Q@mail.gmail.com>

Can you point me where the logs are?

I suspect one issue per arch is the best approach.

Tom

On Tue, Oct 6, 2015 at 6:57 PM Sandro Tosi <morph at debian.org> wrote:

> first of all, thanks a lot for the prompt support in making mpl ready
> to be uploaded to Debian! which happened last night, and it is mostly
> built on all our official architectures (except mips, it's taking its
> time to be built there eheh), but there are some unittest failures,
> how do you want me to report them: one issue per arcihtecture? all of
> them together? something else? I expect most of them will be wontfix,
> but some might uncover hidden bugs
>
> On Mon, Oct 5, 2015 at 5:32 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:
> > Sandro Tosi <morph at debian.org> writes:
> >
> >> in the meantime a new error came up, while building latex doc:
> >>
> >> ```
> >> Adding blank page after the table of contents.
> >> [1] [2] [1] [2]
> >> Chapter 1.
> >> (/usr/share/texlive/texmf-dist/tex/latex/txfonts/t1txtt.fd)
> >>
> >> ! Package inputenc Error: Unicode char \u8:? not set up for use with
> LaTeX.
> >>
> >> See the inputenc package documentation for explanation.
> >> Type  H <return>  for immediate help.
> >>  ...
> >>
> >> l.163 Ste?
> >>            fan van der Walt's talk from SciPy2015
> >
> > The letter ? in the source file is encoded using U+0301 COMBINING ACUTE
> > ACCENT (UTF-8 bytes cc 81):
> >
> > $ git grep 'van der W' | hexdump -C
> > 00000000  73 74 79 6c 65 5f 63 68  61 6e 67 65 73 2e 72 73  |
> style_changes.rs|
> > 00000010  74 3a 53 74 65 cc 81 66  61 6e 20 76 61 6e 20 64  |t:Ste..fan
> van d|
> > 00000020  65 72 20 57 61 6c 74 27  73 20 74 61 6c 6b 20 66  |er Walt's
> talk f|
> > 00000030  72 6f 6d 20 53 63 69 50  79 32 30 31 35 0a        |rom
> SciPy2015.|
> > 0000003e
> >
> > LaTeX would probably understand U+00E9 LATIN SMALL LETTER E WITH ACUTE
> > better. I'll make a PR.
> >
> > --
> > Jouni K. Sepp?nen
> > http://www.iki.fi/jks
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> _______________________________________________
> 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/20151006/55fb876d/attachment.html>

From morph at debian.org  Wed Oct  7 01:02:23 2015
From: morph at debian.org (Sandro Tosi)
Date: Wed, 7 Oct 2015 00:02:23 +0100
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAA48SF-9mtjYJkcOTpQ+v8QUL7gxuX79uG0V9FgihuqTTf+B6Q@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
 <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
 <CAB4XWXx4Wg_PC4p3=QQPaXUsp4fK139+R4pqAKOC3MVZffp1XA@mail.gmail.com>
 <m24mi6c4vy.fsf@jks.iki.fi>
 <CAB4XWXwih_8-JhEjGH6-MXrTSkFchBefA0Y4gGvaqrQwuPw4DA@mail.gmail.com>
 <CAA48SF-9mtjYJkcOTpQ+v8QUL7gxuX79uG0V9FgihuqTTf+B6Q@mail.gmail.com>
Message-ID: <CAB4XWXw4UaPES76S1uw8NB4Q--Qa+uBPv5+Bif+Bd+KMjPO_Jw@mail.gmail.com>

sure here they are:
https://buildd.debian.org/status/package.php?p=matplotlib&suite=sid
(you will have to click on "all (1)" for each arch and then on the
Maybe-Succesful) if you skim thru some of them, lemme know which one I
can skip before submitting duplicate issues

On Tue, Oct 6, 2015 at 11:59 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> Can you point me where the logs are?
>
> I suspect one issue per arch is the best approach.
>
> Tom
>
> On Tue, Oct 6, 2015 at 6:57 PM Sandro Tosi <morph at debian.org> wrote:
>>
>> first of all, thanks a lot for the prompt support in making mpl ready
>> to be uploaded to Debian! which happened last night, and it is mostly
>> built on all our official architectures (except mips, it's taking its
>> time to be built there eheh), but there are some unittest failures,
>> how do you want me to report them: one issue per arcihtecture? all of
>> them together? something else? I expect most of them will be wontfix,
>> but some might uncover hidden bugs
>>
>> On Mon, Oct 5, 2015 at 5:32 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:
>> > Sandro Tosi <morph at debian.org> writes:
>> >
>> >> in the meantime a new error came up, while building latex doc:
>> >>
>> >> ```
>> >> Adding blank page after the table of contents.
>> >> [1] [2] [1] [2]
>> >> Chapter 1.
>> >> (/usr/share/texlive/texmf-dist/tex/latex/txfonts/t1txtt.fd)
>> >>
>> >> ! Package inputenc Error: Unicode char \u8:? not set up for use with
>> >> LaTeX.
>> >>
>> >> See the inputenc package documentation for explanation.
>> >> Type  H <return>  for immediate help.
>> >>  ...
>> >>
>> >> l.163 Ste?
>> >>            fan van der Walt's talk from SciPy2015
>> >
>> > The letter ? in the source file is encoded using U+0301 COMBINING ACUTE
>> > ACCENT (UTF-8 bytes cc 81):
>> >
>> > $ git grep 'van der W' | hexdump -C
>> > 00000000  73 74 79 6c 65 5f 63 68  61 6e 67 65 73 2e 72 73
>> > |style_changes.rs|
>> > 00000010  74 3a 53 74 65 cc 81 66  61 6e 20 76 61 6e 20 64  |t:Ste..fan
>> > van d|
>> > 00000020  65 72 20 57 61 6c 74 27  73 20 74 61 6c 6b 20 66  |er Walt's
>> > talk f|
>> > 00000030  72 6f 6d 20 53 63 69 50  79 32 30 31 35 0a        |rom
>> > SciPy2015.|
>> > 0000003e
>> >
>> > LaTeX would probably understand U+00E9 LATIN SMALL LETTER E WITH ACUTE
>> > better. I'll make a PR.
>> >
>> > --
>> > Jouni K. Sepp?nen
>> > http://www.iki.fi/jks
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel at python.org
>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From tcaswell at gmail.com  Wed Oct  7 03:17:32 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Wed, 07 Oct 2015 01:17:32 +0000
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAB4XWXw4UaPES76S1uw8NB4Q--Qa+uBPv5+Bif+Bd+KMjPO_Jw@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
 <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>
 <CAA48SF-rLxGbtLsveUi328VWNZDvGe078Lhcuky=po+6uVcitg@mail.gmail.com>
 <CAA48SF-Ua4sLK-VtsDXaagVUPeQg=bU55+=Y_eRmVQz8F6a0Dg@mail.gmail.com>
 <CAB4XWXx4Wg_PC4p3=QQPaXUsp4fK139+R4pqAKOC3MVZffp1XA@mail.gmail.com>
 <m24mi6c4vy.fsf@jks.iki.fi>
 <CAB4XWXwih_8-JhEjGH6-MXrTSkFchBefA0Y4gGvaqrQwuPw4DA@mail.gmail.com>
 <CAA48SF-9mtjYJkcOTpQ+v8QUL7gxuX79uG0V9FgihuqTTf+B6Q@mail.gmail.com>
 <CAB4XWXw4UaPES76S1uw8NB4Q--Qa+uBPv5+Bif+Bd+KMjPO_Jw@mail.gmail.com>
Message-ID: <CAA48SF9OTvZMjLUnnouFm2k6fWYBCczMZB1vBjYw+j8R_DtkAQ@mail.gmail.com>

It looks like on arm and powerpc some of the spectral computations in mlap
are returning complex instead of real values which is odd.

My guess on the sphinx issue is that the version of sphinx that is being
spawned via a `Popen` call does not have the right PYTHONPATH and is trying
to import a non-built version of matplotlib.

The tight-layout fail is one that we see intermittently on travis.

Those logs are burly.

On Tue, Oct 6, 2015 at 7:02 PM Sandro Tosi <morph at debian.org> wrote:

> sure here they are:
> https://buildd.debian.org/status/package.php?p=matplotlib&suite=sid
> (you will have to click on "all (1)" for each arch and then on the
> Maybe-Succesful) if you skim thru some of them, lemme know which one I
> can skip before submitting duplicate issues
>
> On Tue, Oct 6, 2015 at 11:59 PM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
> > Can you point me where the logs are?
> >
> > I suspect one issue per arch is the best approach.
> >
> > Tom
> >
> > On Tue, Oct 6, 2015 at 6:57 PM Sandro Tosi <morph at debian.org> wrote:
> >>
> >> first of all, thanks a lot for the prompt support in making mpl ready
> >> to be uploaded to Debian! which happened last night, and it is mostly
> >> built on all our official architectures (except mips, it's taking its
> >> time to be built there eheh), but there are some unittest failures,
> >> how do you want me to report them: one issue per arcihtecture? all of
> >> them together? something else? I expect most of them will be wontfix,
> >> but some might uncover hidden bugs
> >>
> >> On Mon, Oct 5, 2015 at 5:32 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:
> >> > Sandro Tosi <morph at debian.org> writes:
> >> >
> >> >> in the meantime a new error came up, while building latex doc:
> >> >>
> >> >> ```
> >> >> Adding blank page after the table of contents.
> >> >> [1] [2] [1] [2]
> >> >> Chapter 1.
> >> >> (/usr/share/texlive/texmf-dist/tex/latex/txfonts/t1txtt.fd)
> >> >>
> >> >> ! Package inputenc Error: Unicode char \u8:? not set up for use with
> >> >> LaTeX.
> >> >>
> >> >> See the inputenc package documentation for explanation.
> >> >> Type  H <return>  for immediate help.
> >> >>  ...
> >> >>
> >> >> l.163 Ste?
> >> >>            fan van der Walt's talk from SciPy2015
> >> >
> >> > The letter ? in the source file is encoded using U+0301 COMBINING
> ACUTE
> >> > ACCENT (UTF-8 bytes cc 81):
> >> >
> >> > $ git grep 'van der W' | hexdump -C
> >> > 00000000  73 74 79 6c 65 5f 63 68  61 6e 67 65 73 2e 72 73
> >> > |style_changes.rs|
> >> > 00000010  74 3a 53 74 65 cc 81 66  61 6e 20 76 61 6e 20 64
> |t:Ste..fan
> >> > van d|
> >> > 00000020  65 72 20 57 61 6c 74 27  73 20 74 61 6c 6b 20 66  |er Walt's
> >> > talk f|
> >> > 00000030  72 6f 6d 20 53 63 69 50  79 32 30 31 35 0a        |rom
> >> > SciPy2015.|
> >> > 0000003e
> >> >
> >> > LaTeX would probably understand U+00E9 LATIN SMALL LETTER E WITH ACUTE
> >> > better. I'll make a PR.
> >> >
> >> > --
> >> > Jouni K. Sepp?nen
> >> > http://www.iki.fi/jks
> >> >
> >> > _______________________________________________
> >> > Matplotlib-devel mailing list
> >> > Matplotlib-devel at python.org
> >> > https://mail.python.org/mailman/listinfo/matplotlib-devel
> >>
> >> --
> >> Sandro Tosi (aka morph, morpheus, matrixhasu)
> >> My website: http://matrixhasu.altervista.org/
> >> Me at Debian: http://wiki.debian.org/SandroTosi
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Matplotlib-devel at python.org
> >> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151007/3781d89b/attachment-0001.html>

From tcaswell at gmail.com  Thu Oct  8 21:52:47 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Thu, 08 Oct 2015 19:52:47 +0000
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
Message-ID: <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151008/80eefc16/attachment.html>

From njs at pobox.com  Thu Oct  8 21:57:29 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 8 Oct 2015 12:57:29 -0700
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
 <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
Message-ID: <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151008/d78d6267/attachment-0001.html>

From tcaswell at gmail.com  Thu Oct  8 22:12:55 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Thu, 08 Oct 2015 20:12:55 +0000
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
 <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
 <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>
Message-ID: <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151008/4e4e5dd1/attachment.html>

From nathan12343 at gmail.com  Thu Oct  8 22:16:25 2015
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Thu, 8 Oct 2015 15:16:25 -0500
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
 <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
 <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>
 <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>
Message-ID: <CAJXewO==HQfBX5UshdyOMq6NEiPT9ye5Wxc2yo7+9uHnxUCMug@mail.gmail.com>

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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>> <javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
>>>>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Matplotlib-devel at python.org
>>>>> <javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
>>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Matplotlib-devel at python.org
>>>> <javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel at python.org
>>> <javascript:_e(%7B%7D,'cvml','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/0663cd31/attachment-0001.html>

From ariza.federico at gmail.com  Thu Oct  8 22:21:46 2015
From: ariza.federico at gmail.com (Federico Ariza)
Date: Thu, 8 Oct 2015 16:21:46 -0400
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CAJXewO==HQfBX5UshdyOMq6NEiPT9ye5Wxc2yo7+9uHnxUCMug@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
 <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
 <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>
 <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>
 <CAJXewO==HQfBX5UshdyOMq6NEiPT9ye5Wxc2yo7+9uHnxUCMug@mail.gmail.com>
Message-ID: <CAA5CsYdt58anXs+X9aAnnUwLKWR2Zw3FVdJmmYDM-FdJNpKXAQ@mail.gmail.com>

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>

From njs at pobox.com  Fri Oct  9 00:57:44 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 8 Oct 2015 15:57:44 -0700
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
 <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
 <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>
 <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>
Message-ID: <CAPJVwBmYXehnAXOyAaZ5Wtug2pXcb1SNt5_aJxdnBBcT79wvOA@mail.gmail.com>

Clarity is nine-tenths of grace :-)
On Oct 8, 2015 1:13 PM, "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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151008/90069205/attachment-0001.html>

From juichenieder-nabb at yahoo.co.uk  Fri Oct  9 01:22:25 2015
From: juichenieder-nabb at yahoo.co.uk (OceanWolf)
Date: Fri, 09 Oct 2015 01:22:25 +0200
Subject: [Matplotlib-devel] supported python versions
In-Reply-To: <CAPJVwBmYXehnAXOyAaZ5Wtug2pXcb1SNt5_aJxdnBBcT79wvOA@mail.gmail.com>
References: <CAA48SF8bTiWywLv-8RK3CVFH0pg=RQFSyzosPGay8JKEe=KWhw@mail.gmail.com>
 <55F7FC90.40500@grinta.net>
 <CAA48SF-SyF-+axrYhXbP8iM7+G0CKXeftcREXq+7ULXMPMBdtg@mail.gmail.com>
 <CAA48SF-QPoCnwtgMgDgJmFXA545zstuG598m2Xt8a+tGnwibUQ@mail.gmail.com>
 <5607E619.3040108@grinta.net> <56081949.9060203@yahoo.co.uk>
 <CAA48SF8AeZo_s0VHRsaK9==2H3Y_WfHMW4OT+kZ97V-bN8ERpg@mail.gmail.com>
 <5608FF8A.6070902@grinta.net>
 <CAGMHX_37LOc38kETGTB2+=JTCREhe5HniWFf41Xx4c42v+oetg@mail.gmail.com>
 <CANNq6Fn58Q7p6gCpL+O0Bp3h7FzY_xt97Ekwm4rTFZXcKAw9UA@mail.gmail.com>
 <CAA48SF-7t+ijuNvpbds8TZFaBDAn39bdcvrp_oUOtZHH8sh7tg@mail.gmail.com>
 <CAPJVwBnwj8FkL0sVoFSWtrbNGu6Q9bQFHom6RQJ-nn3SDF6N3A@mail.gmail.com>
 <CAA48SF-0q7bCnvHUixwfLjEkERYS4hSuHmcy811ivJvJ8MUYZA@mail.gmail.com>
 <CAPJVwBmYXehnAXOyAaZ5Wtug2pXcb1SNt5_aJxdnBBcT79wvOA@mail.gmail.com>
Message-ID: <5616FAB1.3050402@yahoo.co.uk>

I think it possible for anyone to misinterpret whatever we say, making 
it clear to 100% of people will become impossible.  Otherwise we just 
end up bikeshedding.  After all, all this effort over wording etcetera 
can only benefit py2.6 users, so do we deem that worth the effort?  
Those 2.6 users who don't understand and don't try to understand and get 
annoyed at us for not understanding when we tried to tell them that they 
use outdated software and should update.

Anyway, for wording how about:
"As of matplotlib2 we no longer support python2.6, (parts of) matplotlib 
may still continue to work with python2.6, but you should treat this as 
luck and not as by design."

With Tom having the final say so as to avoid this bikeshedding...

On 09/10/15 00:57, Nathaniel Smith wrote:
>
> Clarity is nine-tenths of grace :-)
>
> On Oct 8, 2015 1:13 PM, "Thomas Caswell" <tcaswell at gmail.com 
> <mailto: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
>     <mailto: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
>         <mailto: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 <mailto: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
>                 <mailto: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
>                     <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
>                 <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/20151009/a5f5c3b6/attachment-0001.html>

From morph at debian.org  Sun Oct  4 21:42:50 2015
From: morph at debian.org (Sandro Tosi)
Date: Sun, 4 Oct 2015 20:42:50 +0100
Subject: [Matplotlib-devel] v1.5.0rc2
In-Reply-To: <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
References: <CAA48SF-eMq=fKNVLRoVQ9no86HP9YGsUW2+nu2COinf8me0Rtg@mail.gmail.com>
 <CAB4XWXxRjcdo8uUDTidvpv+8tgObJX06AS1rLuRBSyj-8=5sKw@mail.gmail.com>
 <CAA48SF_13yn7ZpPLY8ApjtvGGn61GKgLOcxL_vUKXdHJUgNr2Q@mail.gmail.com>
 <CAB4XWXwDdzBdtKRzcziskvwFPQqwpRP9qMH6cMcPHkjoEODcFg@mail.gmail.com>
Message-ID: <CAB4XWXy7HkDoewo9Cb6xVVpoa31uCgx4TDjMTjZeLxsKwbnVmg@mail.gmail.com>

Ok, i managed to reach the point where I can build mpl on debian, but
I'm getting some weird unittest failures (cut&paste will suck, so I'm
also attaching the full build log):

```
ERROR: matplotlib.tests.test_style.test_use_url
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/tests/test_style.py",
line 61, in test_use_url
    with style.context('https://gist.github.com/adrn/6590261/raw'):
  File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/style/core.py",
line 121, in context
    use(style)
  File "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/style/core.py",
line 90, in use
    raise IOError(msg % style)
IOError: 'https://gist.github.com/adrn/6590261/raw' not found in the
style library and input is not a valid URL or path. See
`style.available` for list of available styles.
```

it seems the test is trying to reach a remote URL (and fails): in
debian we dont allow package to reach the internet when building, any
suggestions how to disable this test?

```
ERROR: Failure: RuntimeError (PyQt{4,5} bindings found despite sip importing
Please install PyQt4 or PyQt5, uninstall sip or explicitly set the
pyside backend.)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 409, in
loadTestsFromName
    module = resolve_name(addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/util.py", line 312, in
resolve_name
    module = __import__('.'.join(parts_copy))
  File "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/tests/test_backend_qt4.py",
line 19, in <module>
    from matplotlib.backends.qt_compat import QtCore
  File "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7/matplotlib/backends/qt_compat.py",
line 144, in <module>
    raise RuntimeError("PyQt{4,5} bindings found despite sip importing\n"
RuntimeError: PyQt{4,5} bindings found despite sip importing
Please install PyQt4 or PyQt5, uninstall sip or explicitly set the
pyside backend.
```

I'm not sure I understand what it's trying to say. there are indeed by
Qt4 and Qt5 available as long as Sip (as it's a dependency of PyQt5),
so what is the problem there? note it worked with 1.4.x with these
packges set.

```
ERROR: test suite for <class
'matplotlib.sphinxext.tests.test_tinypages.TestTinyPages'>
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 209, in run
    self.setUp()
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 292, in setUp
    self.setupContext(ancestor)
  File "/usr/lib/python2.7/dist-packages/nose/suite.py", line 315, in
setupContext
    try_run(context, names)
  File "/usr/lib/python2.7/dist-packages/nose/util.py", line 471, in try_run
    return func()
  File "/tmp/buildd/matplotlib-1.5.0~rc2/build/lib.linux-x86_64-2.7-pydebug/matplotlib/sphinxext/tests/test_tinypages.py",
line 58, in setup_class
    out, err))
RuntimeError: sphinx-build failed with stdout:
Running Sphinx v1.3.1
making output directory...

stderr:

Extension error:
Could not import extension matplotlib.sphinxext.plot_directive
(exception: No module named _path)
```

I dont know what this _path should be imported  from, as after
grepping a bit I was not able to identify that.

let me know if you want me to report them as bugs or this email is fine.


On Sun, Oct 4, 2015 at 12:47 PM, Sandro Tosi <morph at debian.org> wrote:
> On Sun, Oct 4, 2015 at 3:43 AM, Thomas Caswell <tcaswell at gmail.com> wrote:
>> It is a hard dependency, but it is only a few hundred line python file.
>
> that's ok, I'll get it packaged and will ask to be fast tracked for acceptance.
>
>> If getting it in as a top-level debian package is not possible, it should
>> not be too hard to vendor it.
>>
>> My preference would be if you could handle this as a debian-specific
>> vendoring, but if this is really a blocker for debian (at it's down-stream
>> ecosystem) we can work something out up upstream.
>>
>> When we started working on cycler part of the discussion was to split it off
>> because down-stream packagers liked to split things up!
>
> hehe, yeah we usually do (even though it sometimes makes our own lives
> harder ;) )
>
> thanks for the quick reply!
>
>>
>> Tom
>>
>> On Sat, Oct 3, 2015 at 8:02 PM Sandro Tosi <morph at debian.org> wrote:
>>>
>>> Hey! I'm working to get this into Debian, so I'd like to understand
>>> how strong the dependency against cycler is: is there a way to opt-out
>>> from it at the moment? We dont have it already available, and avoiding
>>> that dependency will help us the mpl in Debian (which in turn will
>>> help Debian migrate to python3.5)
>>>
>>> Thanks!
>>>
>>> On Sat, Oct 3, 2015 at 12:04 AM, Thomas Caswell <tcaswell at gmail.com>
>>> wrote:
>>> > Hey folks,
>>> >
>>> > I have tagged v1.5.0rc2 and created a v1.5.x branch on upstream.
>>> > Hopefully
>>> > the new conda packages will be available on `-c conda-forge` within the
>>> > next
>>> > day or so.
>>> >
>>> > Please open any new PRs targetted for 1.5.0 against the v1.5.x branch
>>> > and
>>> > remember to cherry pick the few open PRs for 1.5.0 back to 1.5.x when
>>> > you
>>> > merge them (or ping me to do it).
>>> >
>>> > Feel free to begin merging new features into master again.
>>> >
>>> > In addition to the normal release notes we should plan to also write
>>> > several
>>> > blog posts for the numfocus blog.  I think it would be good to have a
>>> > post
>>> > for at least each of
>>> >   - property cycling
>>> >   - labeled data plotting
>>> >   - auto-redraw
>>> >   - %matplotlib notebook
>>> >   - the new color maps
>>> >   - the style module + new style sheets
>>> >
>>> > Any volunteers to write those?
>>> >
>>> > Tom
>>> >
>>> > _______________________________________________
>>> > Matplotlib-devel mailing list
>>> > Matplotlib-devel at python.org
>>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>>> >
>>>
>>>
>>>
>>> --
>>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>>> My website: http://matrixhasu.altervista.org/
>>> Me at Debian: http://wiki.debian.org/SandroTosi
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matplotlib_1.5.0~rc2-1_amd64.build.bz2
Type: application/x-bzip2
Size: 87415 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151004/10a7b67b/attachment-0001.bin>

From mrngilles at gmail.com  Mon Oct  5 17:51:11 2015
From: mrngilles at gmail.com (Marin GILLES)
Date: Mon, 5 Oct 2015 17:51:11 +0200
Subject: [Matplotlib-devel] SVG test issue
Message-ID: <56129C6F.5060702@gmail.com>

Hello everyone,

I am trying to run the test suite, but the conversion SVG -> PNG seems 
to have some issues. I think it comes from my part, but would like some 
help if you already encoutered the issue.
I am running inkscape 0.91, which may be why there is some issue as SVG 
is converted thanks to inkscape, although it seems the expected png is 
generated on the fly too, which would mean using the same software...

Thank you

-- 
*Marin GILLES*
/PhD student CNRS
/ /Laboratoire Interdisciplinaire Carnot de Bourgogne (ICB)
UMR 6303 CNRS - Universit? de Bourgogne
9 av Alain Savary, BP 47870
21078, Dijon (France)
/ ? (+33)6.79.35.30.11
? marin.gilles at u-bourgogne.fr <mailto:marin.gilles at u-bourgogne.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151005/b6e5f4b2/attachment.html>

From tcaswell at gmail.com  Fri Oct  9 05:12:59 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 09 Oct 2015 03:12:59 +0000
Subject: [Matplotlib-devel] SVG test issue
In-Reply-To: <56129C6F.5060702@gmail.com>
References: <56129C6F.5060702@gmail.com>
Message-ID: <CAA48SF9YA24pspG62CDzAy2tWaWsa3CLYDRi6NuOB1_-1nuKOA@mail.gmail.com>

Can you provide any more details?  There are lots of ways that the svg ->
png can go wrong.

0.91 seems to be the most recent version (that is what arch ships ;) ) and
works correctly on my machine.

Tom

On Thu, Oct 8, 2015 at 7:38 PM Marin GILLES <mrngilles at gmail.com> wrote:

> Hello everyone,
>
> I am trying to run the test suite, but the conversion SVG -> PNG seems to
> have some issues. I think it comes from my part, but would like some help
> if you already encoutered the issue.
> I am running inkscape 0.91, which may be why there is some issue as SVG is
> converted thanks to inkscape, although it seems the expected png is
> generated on the fly too, which would mean using the same software...
>
> Thank you
>
> --
> *Marin GILLES*
>
> *PhD student CNRS *
>
>
>
> * Laboratoire Interdisciplinaire Carnot de Bourgogne (ICB) UMR 6303 CNRS -
> Universit? de Bourgogne 9 av Alain Savary, BP 47870 21078, Dijon (France) *
> ? (+33)6.79.35.30.11
> ? marin.gilles at u-bourgogne.fr
> _______________________________________________
> 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/20151009/137822f6/attachment.html>

From tcaswell at gmail.com  Fri Oct  9 05:21:47 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 09 Oct 2015 03:21:47 +0000
Subject: [Matplotlib-devel] [Error 17]No usable Temporary file name
	found.
In-Reply-To: <1443208765933-46219.post@n5.nabble.com>
References: <1443208765933-46219.post@n5.nabble.com>
Message-ID: <CAA48SF9k=zcD631J=O31A2qSyKu13G80PhhNWcKQoc9rO0ScdA@mail.gmail.com>

Srinath,

This does seem to be a persistent problem (I have seen py2exe related
questions go by a number of times), but unfortunately one I do not know how
to solve.

I suspect that this is more of an issue with py2exe / it's configuration,
you might do better reaching out to the py2exe mailing list (and then
making sure their answer makes it into our docs!).

Tom

On Thu, Oct 8, 2015 at 7:38 PM programmer86 <penugondasrinath at gmail.com>
wrote:

> Hi,
>
> I developed a tool in Python 2.7.8 and packaged it using "py2exe". When I
> run the tool I get the following error
>
> Traceback (most recent call last):
>
>   File "application_gui.py", line 2, in <module>
>   File "modules\Application.pyc", line 13, in <module>
>   File "modules\Base.pyc", line 15, in <module>
>   File "matplotlib\__init__.pyc", line 764, in <module>
>   File "matplotlib\__init__.pyc", line 682, in rc_params
>   File "matplotlib\__init__.pyc", line 595, in matplotlib_fname
>   File "matplotlib\__init__.pyc", line 248, in wrapper
>   File "matplotlib\__init__.pyc", line 470, in _get_configdir
>   File "matplotlib\__init__.pyc", line 176, in _is_writable_dir
>   File "tempfile.pyc", line 462, in NamedTemporaryFile
>   File "tempfile.pyc", line 251, in _mkstemp_inner
>
> IOError: [Errno 17] No usable temporary file name found
>
>
> I am using matplotlib 1.4.3.
>
> Thanks,
> Srinath.
>
>
>
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/Error-17-No-usable-Temporary-file-name-found-tp46219.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
> _______________________________________________
> 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/20151009/609f194d/attachment.html>

From toddrjen at gmail.com  Tue Oct 13 10:04:28 2015
From: toddrjen at gmail.com (Todd)
Date: Tue, 13 Oct 2015 10:04:28 +0200
Subject: [Matplotlib-devel] MPL2 Logo
In-Reply-To: <61BC32FF-909B-4CC5-9976-695962652B58@inria.fr>
References: <56048B26.7060903@yahoo.co.uk>
 <CANNq6Fmwq2XPwGDsPPhE6m440FKH=wcm8jYLirJ+oCrWe=fSGA@mail.gmail.com>
 <CAA48SF-BcMcMoLgyU7xosPW6N48Vm+LnOSH+2z=UT=J+uMpVVA@mail.gmail.com>
 <560A9459.80406@stsci.edu> <560AD906.9060709@hawaii.edu>
 <61BC32FF-909B-4CC5-9976-695962652B58@inria.fr>
Message-ID: <CAFpSVpLG=+r9LUhHEtSf5LQ+fnYf2F6Pzhv7Q7imNsGiaux-3Q@mail.gmail.com>

On Sep 29, 2015 9:06 PM, "Nicolas P. Rougier" <Nicolas.Rougier at inria.fr>
wrote:
>
>
> Just my two cents but the unusual size of the logo makes it difficult to
integrate at various places.
> I've made a cover for the scipy lecture notes (hidden advertisement, see
http://www.scipy-lectures.org) and I was unable to properly integrate it.
>
> In the end, I chose to make a brand new one (see below).
> I'm not saying this new one is better, but it would be good to have a
more "square" version of the current logo.

I think there would probably need to be 3 versions of the logo.  The first
would be the current one.  The second would be for presentations, and would
probably be a square one with just the plot with the matplotlib name below
it.  The third would be for icons (taskbar icons, favicons, etc), and would
probably be just the plot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151013/9490d99e/attachment.html>

From ben.v.root at gmail.com  Fri Oct 16 18:19:28 2015
From: ben.v.root at gmail.com (Benjamin Root)
Date: Fri, 16 Oct 2015 12:19:28 -0400
Subject: [Matplotlib-devel] Generalize BoxStyle?
Message-ID: <CANNq6Fmuikmv34WnRm6hMj0bFj6TjOriXND5WUPBqmaR-H7aWw@mail.gmail.com>

Looking into the recent "how to make a toothed curve" question, I started
to wonder if the BoxStyle stuff could be refactored into something composed
of draw style mutators, and at the same time rework the current draw style
implementation? This way, one can easily create fancy lines or boxes, all
using the same code and what-ever options are available for boxes are also
available for lines.

Does anyone see a roadblock/pitfall with this idea?

(note, I am aware that this wouldn't solve the original poster's question
because the sawtooth wouldn't be filled in, but it would be neat to have
anyway).

Cheers!
Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151016/5d29dd69/attachment.html>

From ben.v.root at gmail.com  Fri Oct 16 18:38:18 2015
From: ben.v.root at gmail.com (Benjamin Root)
Date: Fri, 16 Oct 2015 12:38:18 -0400
Subject: [Matplotlib-devel] Generalize BoxStyle?
In-Reply-To: <CANNq6Fmuikmv34WnRm6hMj0bFj6TjOriXND5WUPBqmaR-H7aWw@mail.gmail.com>
References: <CANNq6Fmuikmv34WnRm6hMj0bFj6TjOriXND5WUPBqmaR-H7aWw@mail.gmail.com>
Message-ID: <CANNq6F=G-Vru0SCJ6ayu+xyiF0zp=_TMUKZ7cSwha7wb63X1iQ@mail.gmail.com>

I see that there are ConnectionStyles, which is used for annotations,
obviously. Maybe this class would also benefit from having a base
"PathStyle" that BoxStyle and ConnectionStyle could work from. It would
probably de-duplicate a lot of code and make it possible to have fewer
lists of styles? At the very least, I think the steps-mid, steps-pre, etc.
drawstyles could be re-implemented as a PathStyle, which ConnectionStyle
could benefit from.

On Fri, Oct 16, 2015 at 12:19 PM, Benjamin Root <ben.v.root at gmail.com>
wrote:

> Looking into the recent "how to make a toothed curve" question, I started
> to wonder if the BoxStyle stuff could be refactored into something composed
> of draw style mutators, and at the same time rework the current draw style
> implementation? This way, one can easily create fancy lines or boxes, all
> using the same code and what-ever options are available for boxes are also
> available for lines.
>
> Does anyone see a roadblock/pitfall with this idea?
>
> (note, I am aware that this wouldn't solve the original poster's question
> because the sawtooth wouldn't be filled in, but it would be neat to have
> anyway).
>
> Cheers!
> Ben Root
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151016/186c07ca/attachment.html>

From mdroettboom at continuum.io  Thu Oct 22 17:07:12 2015
From: mdroettboom at continuum.io (Michael Droettboom)
Date: Thu, 22 Oct 2015 11:07:12 -0400
Subject: [Matplotlib-devel] v1.5.0rc3
Message-ID: <CADsn3C3D=7e9_whXgctVmodXiTTe-cc8Vrkq-dyNagPwos0seA@mail.gmail.com>

While Thomas is away, I've tagged a 1.5.0rc3 release, as there have been a
number of critical bugfixes since rc2.  Hopefully this will be the last
release candidate before 1.5.0.

As I haven't done a matplotlib release in a while, I'll need to sync with
Thomas about how the conda-forge packages get created before those will be
available.

Cheers,
Mike

-- 
Michael Droettboom
Continuum Analytics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151022/e870ea87/attachment.html>

From matthew.brett at gmail.com  Fri Oct 23 11:05:06 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 23 Oct 2015 11:05:06 -0400
Subject: [Matplotlib-devel] v1.5.0rc3
In-Reply-To: <CADsn3C3D=7e9_whXgctVmodXiTTe-cc8Vrkq-dyNagPwos0seA@mail.gmail.com>
References: <CADsn3C3D=7e9_whXgctVmodXiTTe-cc8Vrkq-dyNagPwos0seA@mail.gmail.com>
Message-ID: <CAH6Pt5rboje7=-mMf9EWxt610bcDtZexLhLyg0Rx+cR_=u5gow@mail.gmail.com>

Hi,

On Thu, Oct 22, 2015 at 11:07 AM, Michael Droettboom
<mdroettboom at continuum.io> wrote:
> While Thomas is away, I've tagged a 1.5.0rc3 release, as there have been a
> number of critical bugfixes since rc2.  Hopefully this will be the last
> release candidate before 1.5.0.
>
> As I haven't done a matplotlib release in a while, I'll need to sync with
> Thomas about how the conda-forge packages get created before those will be
> available.

I built wheels using https://github.com/MacPython/matplotlib-wheels

To test, I believe this will work:

pip install --trusted-host wheels.scipy.org -f http://wheels.scipy.org
-U --pre matplotlib

Cheers,

Matthew

From randint43901492 at gmail.com  Sun Oct 25 21:35:03 2015
From: randint43901492 at gmail.com (SystemRandom ChooseDigit)
Date: Sun, 25 Oct 2015 21:35:03 -0400
Subject: [Matplotlib-devel] Freenode matplotlib topic
Message-ID: <CALnJMVL_civ7RzvqwOMDspd+gYN9Yp0CCbMAkqw9O-LMk+Lgpg@mail.gmail.com>

I've noticed that the topic in #matplotlib on Freenode points to
matplotlib.sf.net:

[#matplotlib] "Welcome to Matplotlib channel. Don't ask and disappear, hang
on channel and help to build an irc-community."
* Channel #matplotlib url: http://matplotlib.sf.net/

Is someone on here an op in that channel and can change the URL?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151025/5969baee/attachment.html>

From mrngilles at gmail.com  Fri Oct  9 03:11:08 2015
From: mrngilles at gmail.com (Marin GILLES)
Date: Fri, 09 Oct 2015 07:11:08 -0000
Subject: [Matplotlib-devel] SVG test issue
In-Reply-To: <CAA48SF9YA24pspG62CDzAy2tWaWsa3CLYDRi6NuOB1_-1nuKOA@mail.gmail.com>
References: <56129C6F.5060702@gmail.com>
 <CAA48SF9YA24pspG62CDzAy2tWaWsa3CLYDRi6NuOB1_-1nuKOA@mail.gmail.com>
Message-ID: <56176882.9020204@gmail.com>

Le 09/10/2015 05:12, Thomas Caswell a ?crit :
> Can you provide any more details?  There are lots of ways that the svg 
> -> png can go wrong.
>
> 0.91 seems to be the most recent version (that is what arch ships ;) ) 
> and works correctly on my machine.
>
> Tom
>
> On Thu, Oct 8, 2015 at 7:38 PM Marin GILLES <mrngilles at gmail.com 
> <mailto:mrngilles at gmail.com>> wrote:
>
>     Hello everyone,
>
>     I am trying to run the test suite, but the conversion SVG -> PNG
>     seems to have some issues. I think it comes from my part, but
>     would like some help if you already encoutered the issue.
>     I am running inkscape 0.91, which may be why there is some issue
>     as SVG is converted thanks to inkscape, although it seems the
>     expected png is generated on the fly too, which would mean using
>     the same software...
>
>     Thank you
>
>     -- 
>     *Marin GILLES*
>     /PhD student CNRS
>     / /Laboratoire Interdisciplinaire Carnot de Bourgogne (ICB)
>     UMR 6303 CNRS - Universit? de Bourgogne
>     9 av Alain Savary, BP 47870
>     21078, Dijon (France)
>     / ? (+33)6.79.35.30.11
>     ? marin.gilles at u-bourgogne.fr <mailto:marin.gilles at u-bourgogne.fr>
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>
It seems I solved the problem by downgrading inkscape to the 0.48.4... 
My mint has some issues, I don't know why. I should try on my arch too, 
I guess it would work.
Thank you guys

-- 
*Marin GILLES*
/PhD student CNRS
/ /Laboratoire Interdisciplinaire Carnot de Bourgogne (ICB)
UMR 6303 CNRS - Universit? de Bourgogne
9 av Alain Savary, BP 47870
21078, Dijon (France)
/ ? (+33)6.79.35.30.11
? marin.gilles at u-bourgogne.fr <mailto:marin.gilles at u-bourgogne.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151009/e18f94dd/attachment.html>

From tcaswell at gmail.com  Thu Oct 29 11:03:41 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Thu, 29 Oct 2015 15:03:41 +0000
Subject: [Matplotlib-devel] gitter room
Message-ID: <CAA48SF842mRDCPxrJztfmpJP64WjKbwsvFCkFXXBbbaY5FeE=Q@mail.gmail.com>

Hey all,

We are experimenting with gitter to see if it is useful to us:

https://gitter.im/matplotlib/matplotlib

The main benefit of this tool that it provides a public, quasi-readable,
high-bandwidth communication tool to move conversations out of private
gchat threads.

IPython uses gitter quite heavily and seems very happy with it.  One thing
they learned is that if any major decisions are made on gitter, a summary
of the discussion and the decision needs to be written up and sent to the
mailing list.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151029/080c2814/attachment.html>

From jerry.li at outlook.com  Thu Oct 29 19:52:59 2015
From: jerry.li at outlook.com (Jerry li)
Date: Fri, 30 Oct 2015 07:52:59 +0800
Subject: [Matplotlib-devel] FW: About linked-brushing features in Matplotlib
In-Reply-To: <SNT147-W493F326D0ABF08EC7FA18D81200@phx.gbl>
References: <SNT147-W493F326D0ABF08EC7FA18D81200@phx.gbl>
Message-ID: <SNT147-W129414C0EBEED36DDF7D3B81200@phx.gbl>

Dear contributors,

I am Jerry, a developer relying on Python to analyze data.
I searched through Matplotlib webpage trying to find a hint about how to make "linked brushing" feature across graphs and data, however it is not successful so far. The "linked-brushing" feature means: taking a scatter plot and a histogram based on the same data for example, when some of the points on the scatter plot are selected, since those points are linked to some data from which the plot is built, the parts of the same data on the histogram will be automatically selected and highlighted too.
The attached is an example from Bokeh plots.

Could I ask:
1. where can I find hints about how to realize this feature with Matplotlib?
2. As there is other visualization packages based on Matplotlib, taking Seaborn as an example, if this feature is realized with Matplotlib, can it be used directly into Seaborn? If yes, could you please share a few hints on how to do that if possible?

Thank you all very much in advance!

Jerry Li
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151030/493b6351/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linked brushing example.png
Type: image/png
Size: 38248 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151030/493b6351/attachment-0001.png>

From tcaswell at gmail.com  Thu Oct 29 22:36:16 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 30 Oct 2015 02:36:16 +0000
Subject: [Matplotlib-devel] FW: About linked-brushing features in
 Matplotlib
In-Reply-To: <SNT147-W129414C0EBEED36DDF7D3B81200@phx.gbl>
References: <SNT147-W493F326D0ABF08EC7FA18D81200@phx.gbl>
 <SNT147-W129414C0EBEED36DDF7D3B81200@phx.gbl>
Message-ID: <CAA48SF-PVusG6H+ZatVY-HLzPZqYxRmrmqhnfzx03+QSvmD7kg@mail.gmail.com>

Glueviz has implemented linked brushing.

Have a look at the lasso demo (
http://matplotlib.org/examples/event_handling/lasso_demo.html), only change
what artist the call back changes.

Tom

On Thu, Oct 29, 2015 at 10:25 PM Jerry li <jerry.li at outlook.com> wrote:

> Dear contributors,
>
> I am Jerry, a developer relying on Python to analyze data.
> I searched through Matplotlib webpage trying to find a hint about how to
> make "linked brushing" feature across graphs and data, however it is not
> successful so far. The "linked-brushing" feature means: taking a scatter
> plot and a histogram based on the same data for example, when some of the
> points on the scatter plot are selected, since those points are linked to
> some data from which the plot is built, the parts of the same data on the
> histogram will be automatically selected and highlighted too.
> The attached is an example from Bokeh plots.
>
> Could I ask:
> 1. where can I find hints about how to realize this feature with
> Matplotlib?
> 2. As there is other visualization packages based on Matplotlib, taking
> Seaborn as an example, if this feature is realized with Matplotlib, can it
> be used directly into Seaborn? If yes, could you please share a few hints
> on how to do that if possible?
>
> Thank you all very much in advance!
>
> Jerry Li
> _______________________________________________
> 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/20151030/7c35d606/attachment.html>

From tcaswell at gmail.com  Thu Oct 29 23:42:51 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 30 Oct 2015 03:42:51 +0000
Subject: [Matplotlib-devel] matplotlib on fedora
Message-ID: <CAA48SF-b3OWyrC67X5ajcdgq3MeiytOH8y0Bvyehe+LVe06LAQ@mail.gmail.com>

Do we have any fedora/red hat users around?  The cycler package needs to be
shepherded  through fedora's package review processes, any volunteers?

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151030/7ad8662b/attachment.html>

From tcaswell at gmail.com  Thu Oct 29 23:44:40 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 30 Oct 2015 03:44:40 +0000
Subject: [Matplotlib-devel] [announce] matplotlib 1.5.0 released
Message-ID: <CAA48SF_LtZ+-2aDkfsrLYbRS-9eWk8Y6zNUcM_xm0PCqNTwU7g@mail.gmail.com>

Hey all,

We are pleased to finally announce the release of matplotlib 1.5.0!  It has
been over a year since the last feature release and we have had over 230
people contribute to this cycle.

This release of matplotlib has several major new features including

 - Auto-redraw using the object-oriented API in interactive mode.
 - Most plotting functions now support labeled data API [Jan Schulz].
 - Color cycling has extended to all style properties [Ben Root].
 - Four new perceptually uniform color maps, including the soon-to-be
default 'viridis'. [Stefan van der Walt and Nathaniel Smith].
 - More included style sheets.
 - Many small plotting improvements.
 - Proposed new framework for managing the GUI toolbar and tools.
 - Pixel-value on mouse over for imshow [Steven Silvester]

For demos of some of these features in action see this notebook:

 https://gist.github.com/tacaswell/72b0d579aeb54d4fbf87

which is version of the talk I presented at scipy, pydata Seattle and
pygotham this summer.  There will be more in-depth demos of the new
features coming.

This release has a new required dependency,  cycler
<http://matplotlib.org/cycler> , for composing complex style cycles.

In 1.5.0 we have dropped official support for python 2.6 and 3.3.

The next matplotlib release will be the 2.0 default-style-only release,
planned for 1-2 months from now.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151030/dc0eb3a1/attachment.html>

From ndbecker2 at gmail.com  Fri Oct 30 08:01:41 2015
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 30 Oct 2015 08:01:41 -0400
Subject: [Matplotlib-devel] matplotlib on fedora
References: <CAA48SF-b3OWyrC67X5ajcdgq3MeiytOH8y0Bvyehe+LVe06LAQ@mail.gmail.com>
Message-ID: <n0vm75$6j9$1@ger.gmane.org>

Thomas Caswell wrote:

> Do we have any fedora/red hat users around?  The cycler package needs to
> be
> shepherded  through fedora's package review processes, any volunteers?
> 
> Tom

If the current maintainer of matplotlib does not want to take it, I can 
volunteer.


From tcaswell at gmail.com  Fri Oct 30 18:25:57 2015
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 30 Oct 2015 22:25:57 +0000
Subject: [Matplotlib-devel] matplotlib on fedora
In-Reply-To: <n0vm75$6j9$1@ger.gmane.org>
References: <CAA48SF-b3OWyrC67X5ajcdgq3MeiytOH8y0Bvyehe+LVe06LAQ@mail.gmail.com>
 <n0vm75$6j9$1@ger.gmane.org>
Message-ID: <CAA48SF_KtFjXzzceXdFWGJrWhy=UFwwpfeU86=5G2otXWB4N_A@mail.gmail.com>

Neal,

That would be great, thanks!

Tom

On Fri, Oct 30, 2015 at 8:01 AM Neal Becker <ndbecker2 at gmail.com> wrote:

> Thomas Caswell wrote:
>
> > Do we have any fedora/red hat users around?  The cycler package needs to
> > be
> > shepherded  through fedora's package review processes, any volunteers?
> >
> > Tom
>
> If the current maintainer of matplotlib does not want to take it, I can
> volunteer.
>
> _______________________________________________
> 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/20151030/dfbb22f3/attachment.html>