matplotlib-devel Mailing List for matplotlib (Page 3)

Hi everyone,
Here is my attempt at making the website:
http://nellev.github.io/tmp/jhepc/index.html
This is still work in progress, but feedback is welcomed.
I chose to display only the "winners" (three top place + honorable mention).
Cheers,
N
On 31 July 2013 17:54, Andy Ray Terrel <and...@gm...> wrote:
> Okay, I'll get it up.
>
> -- Andy
>
>
> On Wed, Jul 31, 2013 at 10:48 AM, Michael Droettboom <md...@st...>wrote:
>
>> On 07/31/2013 11:38 AM, Andy Ray Terrel wrote:
>>
>>
>> The plan was to have it on the SciPy conference website, but we haven't
>> really got it up. If someone can point me to rendered html, I can ask Jim
>> to put it up there now.
>>
>> The rendered HTML is in the scipy2013_talks github repo.
>>
>> https://github.com/scipy/scipy2013_talks/tree/master/plotting_contest
>>
>> That will be fine for now, and it sounds like Nelle will make the
>> presentation much better down the road, at which case we can update it then.
>>
>> Mike
>>
>
>

Hi Mike,
thanks a lot for providing these numbers...
I think for now, the plan we hatched at the dev meeting continues to
look reasonable (integrate interactive webagg support into the
%matplotlib magic so it would be seamless to users on localhost or
very open networks). But the fact that the overhead is lower than
we'd thought lends weight to the idea of giving mpl an easier way to
integrate this functionality into our existing design before we cross
the binary ws bridge...
One way or another, exciting times!
Cheers,
f

On Tue, Jul 30, 2013 at 2:28 PM, Michael Droettboom <md...@st...> wrote:
> As promised in last week's Google Hangout to the IPython developers
> meeting -- I have some concrete timings and numbers on the matplotlib
> WebAgg backend in a couple of different scenarios.
>
> First, let me apologize -- the way I was timing binary websockets vs.
> text websockets previously was wrong. The actual impact of it is much
> smaller than I had originally estimated -- so the discussion about
> whether to include binary websockets in IPython may have been all for
> naught.
>
Part of our message spec includes binary blobs trailing after the JSONable
message dicts.
Currently this is used by `data_pub` and `apply` messages, but it could
theoretically be extended to display data for streaming output, such as
video or audio. Right now, we have no way of propagating that part of the
message spec up to notebook frontends, because we do not yet have any
binary messages that the notebook frontend can understand. In these cases,
a switch to binary websocket may still make sense, even without a
performance argument.
>
> For benchmarking, I used two different plots. One is the classic
> "simple_plot.py" sine wave, which tests sort of the "easy case" where
> very little of the image is updated in each frame, and the other was
> "animation/dynamic_image.py" in which most of the plot is updated in
> each frame.
>
> I tested both scenarios with client and server on my local machine, and
> through an ssh tunnel that goes over wifi, the public university
> network, to my home's 15/5 MBps cable connection 28 miles away and back.
>
> For (A), the average frame weighs in at around 20kb. For (B), it's
> around 90kb. For base64, multiply by those numbers by 4 / 3.
>
> On my local machine, I can push through about 18 fps, so a bandwidth of
> 2.8MBps (were it sustained, which it rarely is). On the tunnel, I
> fluctuate between 7 and 10 fps, which is quite usable, and quite near
> the practical upper limit on the bandwidth of that connection.
>
> However, the problematic thing for the remote connection is the
> latency. Locally, I average a fairly steady 250ms to roundtrip from a
> mouse event to an updated frame. Remotely, it fluctuates randomly
> between 400ms (still usable) and 3000ms. Some more careful dynamic
> scaling of events can probably make that easier to use, perhaps. I know
> games often use UDP and handle robustness to packet loss in a different
> way as a way to remove some of the latency of TCP. I have no idea if
> such a thing would be possible over a web socket, of course.
>
> I could not measure any statistically significant change in framerate or
> latency between a binary websocket and a non-binary one. However, there
> is a 10% increase in CPU time on both the python side and the browser.
> It so happens that I wasn't saturating my CPU, so it had no net impact.
> Likewise, I am not saturating my bandwidth, so the additional size
> doesn't matter in this case. But I suspect if either one of those
> resources is starved, the additional 10% cpu time and 25% bandwidth
> increase may matter.
>
Thanks for these numbers - I suspect the potential penalty for an extra hop
between the kernel and the notebook will not be significant in any case
where the kernel is local to the server and the client is remote.
-MinRK
>
> Mike
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

I am glad that the numpy and scipy projects are still creating binary installers for python.org python, but it is a serious problem for users of the matplotlib binary installers that they are so difficult to find.
If a user googles for "numpy download" then the user finds this page
<http://www.numpy.org>
and the link Getting Numpy points to this page
<http://www.scipy.org/install.html>
which does not the binary installers at all.
I agree that most users should probably use Anaconda or its ilk, but I think it would be good to mention the Mac and Windows python.org binary installers quite prominently after that.
-- Russell
On Aug 7, 2013, at 1:00 PM, Thomas Kluyver <th...@kl...> wrote:
> On 7 August 2013 12:54, Russell E. Owen <ro...@uw...> wrote:
> P.S. the Mac binary installer for numpy used to be easy to find. I was
> quite dismayed to find how buried it had become when I went looking for
> it a week or two ago.
> 
> Is this down to the redesign of the SciPy site. If so, blame me ;-). I felt, and others seemed to agree, that setting up individual packages separately wasn't a route that we wanted to promote to newcomers, so the new site emphasises all-in-one installers that get you the whole Scipy Stack (numpy, scipy, matplotlib, etc.) in one go.
> 
> Thomas

On Wed, Aug 7, 2013 at 4:00 PM, Thomas Kluyver <th...@kl...> wrote:
> On 7 August 2013 12:54, Russell E. Owen <ro...@uw...> wrote:
>
>> P.S. the Mac binary installer for numpy used to be easy to find. I was
>> quite dismayed to find how buried it had become when I went looking for
>> it a week or two ago.
>>
>
> Is this down to the redesign of the SciPy site. If so, blame me ;-). I
> felt, and others seemed to agree, that setting up individual packages
> separately wasn't a route that we wanted to promote to newcomers, so the
> new site emphasises all-in-one installers that get you the whole Scipy
> Stack (numpy, scipy, matplotlib, etc.) in one go.
>
> Thomas
>
>
All-in-one installers are fine, but I don't think it should exclude access
to the individual installers as well (for the intermediate users, for
example).
Ben Root

On 7 August 2013 12:54, Russell E. Owen <ro...@uw...> wrote:
> P.S. the Mac binary installer for numpy used to be easy to find. I was
> quite dismayed to find how buried it had become when I went looking for
> it a week or two ago.
>
Is this down to the redesign of the SciPy site. If so, blame me ;-). I
felt, and others seemed to agree, that setting up individual packages
separately wasn't a route that we wanted to promote to newcomers, so the
new site emphasises all-in-one installers that get you the whole Scipy
Stack (numpy, scipy, matplotlib, etc.) in one go.
Thomas

In article <51F...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> Ludwig, this is one of the most entertaining e-mails I've read in a 
> while, and I think your arguments make a lot of sense.
> 
> Given infinite developer resources, do you think there's any logic to 
> providing *both* system Python and python.org based binaries? How much 
> additional work would that be?
> 
> I think the big problems to solve now is
> 
> (a) get to the bottom of why the new installer is breaking existing 
> installations of dateutil and pytz. Russell: even though they are not 
> currently working, could you provide what you have so that others can 
> have a look?
I put the installer here (and announced it earlier -- I thought in this 
thread):
<http://www.astro.washington.edu/users/rowen/python/>
I do not consider it safe because:
- It may trash existing installations of dateutil and pytz (especially 
those installed by the matplotlib 1.2.1 binary installer)
- It does not include pytz, dateutil and six (unlike the 1.2.1 binary 
installer), so it's a real pain to use
- It is missing its unit tests and so is poorly tested
- It also appears that pylab is broken (something I only recently 
discovered)
Unless somebody figures out how to include the dependencies, I think a 
Mac binary installer is a nonstarter.
-- Russell
P.S. the Mac binary installer for numpy used to be easy to find. I was 
quite dismayed to find how buried it had become when I went looking for 
it a week or two ago.

Ok -- I've redone it as 2 hour blocks -- we may not need that much time, 
but it seemed like the easiest way to make this work.
Cheers,
Mike
On 08/05/2013 11:11 AM, Michael Droettboom wrote:
> Sorry -- bear with me -- I didn't mean to put in really large blocks 
> of time like that. Hold on as I try to fix this.
>
> On 08/05/2013 10:42 AM, Michael Droettboom wrote:
>> I've set up a Doodle poll to find a good time.
>>
>> http://doodle.com/4f3yzii4vv7w93ai
>>
>> Most of the interesting parties are either in North America or Europe 
>> (sorry, Eric: you're the outlier).
>>
>> Cheers,
>> Mike
>>
>> On 08/02/2013 10:05 PM, Matt Terry wrote:
>>>
>>> I don't have any useful experience with CI services, but it would be 
>>> nice to have the ability to test on macos.
>>>
>>> On Aug 2, 2013 6:10 PM, "Benjamin Root" <ben...@ou... 
>>> <mailto:ben...@ou...>> wrote:
>>> >
>>> > +1 for me too
>>> >
>>> > Ben
>>> >
>>> > On Aug 2, 2013 11:04 AM, "Chris Beaumont" <bea...@ha... 
>>> <mailto:bea...@ha...>> wrote:
>>> >>
>>> >> I'd like to sit in on this if I'm available. Please keep me posted
>>> >>
>>> >> Cheers,
>>> >> Chris
>>> >>
>>> >> 
>>> ------------------------------------------------------------------------------
>>> >> Get your SQL database under version control now!
>>> >> Version control is standard for application code, but databases 
>>> havent
>>> >> caught up. So what steps can you take to put your SQL databases under
>>> >> version control? Why should you start doing it? Read more to find 
>>> out.
>>> >> 
>>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>> >> _______________________________________________
>>> >> Matplotlib-devel mailing list
>>> >> Mat...@li... 
>>> <mailto:Mat...@li...>
>>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >>
>>> >
>>> > 
>>> ------------------------------------------------------------------------------
>>> > Get your SQL database under version control now!
>>> > Version control is standard for application code, but databases havent
>>> > caught up. So what steps can you take to put your SQL databases under
>>> > version control? Why should you start doing it? Read more to find out.
>>> > 
>>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Matplotlib-devel mailing list
>>> > Mat...@li... 
>>> <mailto:Mat...@li...>
>>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get your SQL database under version control now!
>>> Version control is standard for application code, but databases havent
>>> caught up. So what steps can you take to put your SQL databases under
>>> version control? Why should you start doing it? Read more to find out.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Sorry -- bear with me -- I didn't mean to put in really large blocks of 
time like that. Hold on as I try to fix this.
On 08/05/2013 10:42 AM, Michael Droettboom wrote:
> I've set up a Doodle poll to find a good time.
>
> http://doodle.com/4f3yzii4vv7w93ai
>
> Most of the interesting parties are either in North America or Europe 
> (sorry, Eric: you're the outlier).
>
> Cheers,
> Mike
>
> On 08/02/2013 10:05 PM, Matt Terry wrote:
>>
>> I don't have any useful experience with CI services, but it would be 
>> nice to have the ability to test on macos.
>>
>> On Aug 2, 2013 6:10 PM, "Benjamin Root" <ben...@ou... 
>> <mailto:ben...@ou...>> wrote:
>> >
>> > +1 for me too
>> >
>> > Ben
>> >
>> > On Aug 2, 2013 11:04 AM, "Chris Beaumont" <bea...@ha... 
>> <mailto:bea...@ha...>> wrote:
>> >>
>> >> I'd like to sit in on this if I'm available. Please keep me posted
>> >>
>> >> Cheers,
>> >> Chris
>> >>
>> >> 
>> ------------------------------------------------------------------------------
>> >> Get your SQL database under version control now!
>> >> Version control is standard for application code, but databases havent
>> >> caught up. So what steps can you take to put your SQL databases under
>> >> version control? Why should you start doing it? Read more to find out.
>> >> 
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Matplotlib-devel mailing list
>> >> Mat...@li... 
>> <mailto:Mat...@li...>
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >
>> > 
>> ------------------------------------------------------------------------------
>> > Get your SQL database under version control now!
>> > Version control is standard for application code, but databases havent
>> > caught up. So what steps can you take to put your SQL databases under
>> > version control? Why should you start doing it? Read more to find out.
>> > 
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li... 
>> <mailto:Mat...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I've set up a Doodle poll to find a good time.
http://doodle.com/4f3yzii4vv7w93ai
Most of the interesting parties are either in North America or Europe 
(sorry, Eric: you're the outlier).
Cheers,
Mike
On 08/02/2013 10:05 PM, Matt Terry wrote:
>
> I don't have any useful experience with CI services, but it would be 
> nice to have the ability to test on macos.
>
> On Aug 2, 2013 6:10 PM, "Benjamin Root" <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
> >
> > +1 for me too
> >
> > Ben
> >
> > On Aug 2, 2013 11:04 AM, "Chris Beaumont" <bea...@ha... 
> <mailto:bea...@ha...>> wrote:
> >>
> >> I'd like to sit in on this if I'm available. Please keep me posted
> >>
> >> Cheers,
> >> Chris
> >>
> >> 
> ------------------------------------------------------------------------------
> >> Get your SQL database under version control now!
> >> Version control is standard for application code, but databases havent
> >> caught up. So what steps can you take to put your SQL databases under
> >> version control? Why should you start doing it? Read more to find out.
> >> 
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >
> > 
> ------------------------------------------------------------------------------
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> > caught up. So what steps can you take to put your SQL databases under
> > version control? Why should you start doing it? Read more to find out.
> > 
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li... 
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I don't have any useful experience with CI services, but it would be nice
to have the ability to test on macos.
On Aug 2, 2013 6:10 PM, "Benjamin Root" <ben...@ou...> wrote:
>
> +1 for me too
>
> Ben
>
> On Aug 2, 2013 11:04 AM, "Chris Beaumont" <bea...@ha...> wrote:
>>
>> I'd like to sit in on this if I'm available. Please keep me posted
>>
>> Cheers,
>> Chris
>>
>>
------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>>
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
>
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

+1 for me too
Ben
On Aug 2, 2013 11:04 AM, "Chris Beaumont" <bea...@ha...> wrote:
> I'd like to sit in on this if I'm available. Please keep me posted
>
> Cheers,
> Chris
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I'd like to sit in on this if I'm available. Please keep me posted
Cheers,
Chris

Yeah -- I was thinking we could start with the list of people who would 
like to attend and then try to schedule (possibly using Doodle) around that.
So, to all: let us know if you would like to attend!
Mike
On 08/02/2013 04:36 AM, Phil Elson wrote:
> Sounds like a good idea to me.
>
> In terms of when - I think the IPython guys have picked a good time 
> (10am US Pacific time, or 5pm GMT/UTC) to have the meeting to maximise 
> the attendance from the Americas and Europe, though I appreciate that 
> no time is perfect for everybody. For instance, I know Eric being in 
> Hawaii–Aleutian Time Zone that time would mean a 7am start, and for 
> JJ, should he wish to join in, it would be a 2am meeting... (for a 
> clock of the places that may need consideration see 
> http://www.timeanddate.com/worldclock/converted.html?iso=20130802T17&p1=0&p2=1358&p3=235&p4=263&p5=137&p6=103).
>
> Did you want to put a date on it Mike? How about we go for a week on 
> Tuesday, say the 2013年08月13日 17:00Z (in your time: 
> http://goo.gl/OnWHBq) - though I'm open to moving it, if that doesn't 
> fit with some of the core contributors who would like to attend. If 
> anybody who knows they would like to attend could notify us here 
> (along with their time zone), we could also try to optimise the time 
> to reduce unsociable hours :-) though we have to acknowledge that 
> there is no such thing as the perfect time...
>
> Cheers,
>
>
>
>
>
>
>
>
> On 1 August 2013 19:58, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>
> (Apologies for cross-posting).
>
> matplotlib has a dire need to improve its continuous integration
> testing. I've drafted MEP19 and solicited comments, but there hasn't
> been a lot of feedback thus far.
>
> As an alternative to mailing list discussion, where this sort of
> upfront
> planning can sometimes be difficult, I'm considering holding a Google
> Hangout in the next few weeks on the subject. It's ok to participate
> even if you don't have the time to work on matplotlib -- I would also
> like feedback from advice from those that have configured similar
> systems for other projects. matplotlib's needs are somewhat more
> complex in terms of dependencies, cpu, ram and storage, so we're
> pushing
> things pretty far here.
>
> If there's enough people with an interest in participating in the
> discussion, I'll send around a Doodle poll to find a good time.
>
> Mike
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Doh! Thanks for pointing that out.
Mike
On 08/02/2013 10:52 AM, Jason Grout wrote:
> On 7/31/13 8:38 AM, Michael Droettboom wrote:
>> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to
>> all involved! It was a long slog getting this release out, and I
>> appreciate everyone's patience.
>>
>> Once we have binaries uploaded to SourceForge, I will make a formal
>> announcement in the usual channels.
>>
> FYI, the downloads page at http://matplotlib.org/downloads.html still
> says that 1.3.0 is a release candidate and 1.2.1 is the latest stable
> version.
>
> Again, thanks for all your work on this!
>
> Jason
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 7/31/13 8:38 AM, Michael Droettboom wrote:
> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to
> all involved! It was a long slog getting this release out, and I
> appreciate everyone's patience.
>
> Once we have binaries uploaded to SourceForge, I will make a formal
> announcement in the usual channels.
>
FYI, the downloads page at http://matplotlib.org/downloads.html still 
says that 1.3.0 is a release candidate and 1.2.1 is the latest stable 
version.
Again, thanks for all your work on this!
Jason

[replying back on list]
On Thu, Aug 1, 2013 at 6:10 PM, Eric Firing <ef...@ha...> wrote:
> On 2013年08月01日 2:06 PM, Matt Terry wrote:
>
>> So you can have both ctrl-alt and alt-control. Is that a meaningful
>> distinction?
>>
>
> In the first case ctrl is a modifier and alt is a key, in the second case
> control is not a modifier but alt is. So one probably would never want to
> assign special functions to each of these, but they are distinct key
> combinations.
> If there were three keys, two modifiers, it would be "ctrl-alt-A". So I'm
> not sure, but I am suggesting that there may be a genuine reason for
> keeping both spellings, and an attempt to go with one or the other might
> have unintended consequences.
>
I don't agree that they are really distinct key combinations, but lets
table that argument.
I do think that control is insufficiently special to deserve a special
case. There should be one (and preferably only one) way to spell control.
QT, for example, does have separate "key" and "modifiers", but it always
spells control Key_Control. Furthermore, we define a order for modifier
keys (ctrl, alt, super), unless control happens to be hit last (though
probably backend dependent) and if there are only modifier keys pressed.
If someone actually wanted to use key_press_event-s in a significant way,
they are going to have to reverse engineer all of these quirks. That seems
silly.

Ludwig, this is one of the most entertaining e-mails I've read in a 
while, and I think your arguments make a lot of sense.
Given infinite developer resources, do you think there's any logic to 
providing *both* system Python and python.org based binaries? How much 
additional work would that be?
I think the big problems to solve now is
(a) get to the bottom of why the new installer is breaking existing 
installations of dateutil and pytz. Russell: even though they are not 
currently working, could you provide what you have so that others can 
have a look?
(b) find a way to include the Python dependencies and perhaps be more 
clever about Numpy. I think using `pip bundle` comes close -- we then 
just need to make a fairly generic installer on top of what it 
produces. Any Mac installer experts out there that want to step up?
Mike
On 08/01/2013 06:45 PM, Ludwig Schwardt wrote:
> Hi Russell (and Mike),
>> Is it useful in the long term to have such a packager? My impression is
>> that as soon as packaging is more robust we'll switch to using pip or
>> easy_install.
> First off, sorry for the long email - got a bit carried away :-) The 
> summary is that I propose we keep the dmg installer but maybe make it 
> use the system Python for reasons illustrated below.
>
> For the record, I'm using pip / easy_install to install matplotlib 
> from source on my Mac and that has been working fine for a while now. 
> You only need to add pkg-config (and the development tools, obviously) 
> to a virgin Mac system and this is now really easy in the days of 
> Homebrew.
>
> Of course, binary packages have the extra issue of a dependency on the 
> environment for which it is built, which complicates matters for 
> binary eggs (thanks for the reminder of wheel, Mike - definitely 
> something to watch). This is the main reason why I don't use the Mac 
> installer dmg: it's built for python.org <http://python.org> Python 
> and I prefer to use system Python instead.
>
> (On this note, it would be interesting to find out how matplotlib 
> people get Python on their Mac these days. My gut feel tells me that 
> Homebrew Python will be quite popular these days, followed by EPD / 
> Anaconda and then maybe python.org <http://python.org> Python. If you 
> use Homebrew there is now the option of "brew install matplotlib" 
> courtesy of Samuel John 
> <https://github.com/samueljohn/homebrew-python/blob/master/matplotlib.rb>, 
> while EPD and Anaconda ship with their own versions of matplotlib, so 
> most of those users are taken care of.)
>
> To answer your original question: I do see a use for a dmg installer 
> in the long term, but one you might not have considered. I picture a 
> Mac user who is not familiar with Python but wants to try out 
> matplotlib (the image of Justin Long saying "Hello, I'm a Mac" somehow 
> comes to mind :-)).
>
> Justin has never heard of easy_install or even a compiler and might 
> not be that comfortable with the Terminal. On the other hand, he is 
> used to installing software by downloading and clicking on a dmg or 
> via the App Store. This is a person who is starting out with these 
> tools and needs as few obstacles as possible to get going. Once he is 
> up and running and likes what he sees, he might be persuaded to 
> install a more full-fledged Python distribution or the rest of the 
> SciPy stack.
>
> As an experiment I put myself in the shoes of Justin. I actually did 
> the steps below on a spare MacBook Pro running Mac OS X 10.7.5 that 
> was unsullied by extra Pythons and rogue matplotlibs and what not.
>
> <BEGIN EXPERIMENT>
>
> Someone told me about "matplotlib" (maybe after seeing a plot in a 
> talk or a paper) which led me to matplotlib.org 
> <http://matplotlib.org> (first Google hit).
>
> I see "Download" and go to the downloads page 
> <http://matplotlib.org/downloads.html>. I see a bunch of links, 
> including these two under "Latest stable version":
>
> matplotlib-1.2.1-py2.7-python.org-macosx10.3.dmg
> matplotlib-1.2.1-py2.7-python.org-macosx10.6.dmg
>
> Since I am on Lion I guess I have to download the latter (although the 
> fact that it says 10.6 and not 10.7 worries me...). I'm not sure what 
> the rest of the filename means - what is py27-python.org 
> <http://py27-python.org>? I download the dmg and open it. I am 
> impatient like most users and click on "Continue".
>
> Oops, there is a problem. The third "Continue" button is grayed out 
> with an error that says: "matplotlib 1.2.1 can't be installed on this 
> disk. matplotlib requires System Python 2.7 to install." [This is 
> ironic because, unbeknownst to Justin, he actually *has* System Python 
> 2.7 installed...] Time to click on "Go Back"... Aah, Important 
> Information (I kick myself for not reading this): "matplotlib for 
> MacOS X 10.6 or later [cool!] and 64-bit Python 2.7 from python.org 
> <http://python.org> (not Apple's built-in Python)". So that's probably 
> what py2.7-python.org <http://py2.7-python.org> refers to. If Justin 
> is patient enough he might also spot the following line: "Before 
> running matplotlib, you must install numpy."
>
> [Clicking "Go Back" would have been the more useful thing to do in 
> this case. If I had decided to return to matplotlib.org 
> <http://matplotlib.org>, I might have seen "Need help?" and clicked on 
> the "faq" link and ended up at the OS-X Notes 
> <http://matplotlib.org/1.3.0/faq/installing_faq.html#os-x-notes>. This 
> mentions "several alternative versions of python" such as EPD, 
> MacPython (yikes, Leopard only!) or python.org <http://python.org>. 
> But the installer only works with the latter... Surprisingly enough I 
> could not find *any* explicit mention in the matplotlib installation 
> docs that you need to install NumPy first. EDIT: Oh wait, it's well 
> documented here <http://matplotlib.org/users/installing.html> but I 
> can only reach this important page by clicking on "docs" in the 
> toolbar below the page title and spotting the "Installing" link. Maybe 
> the "Download" section on the front page should read "Read the 
> installation instructions 
> <http://matplotlib.org/users/installing.html> first and then visit the 
> matplotlib downloads page <http://matplotlib.org/downloads.html>."]
>
> Time to visit python.org <http://python.org>. I see "Download" and 
> then notice "Python 2.7.5 Mac OS X 64-bit/32-bit x86-64/i386 Installer 
> (for Mac OS X 10.6 and later [2])". I download the dmg and click on 
> it. The installation is successful. I go back to the matplotlib dmg 
> and retry the installation - success!
>
> Mmm, what now?
>
> [This is not really matplotlib's problem, but I found surprisingly few 
> resources that tell you how to start Python on the Mac if you know 
> absolutely nothing about Unix and Terminals and such. If you search 
> for "python mac" on Google you at least get some idea at the first hit 
> <http://www.python.org/getit/mac/>. The official Mac usage page 
> <http://docs.python.org/2/using/mac.html> is quite technical but 
> mentions that "your best way to get started with Python on Mac OS X is 
> through the IDLE integrated development environment" which at least 
> gets you to a Python prompt.]
>
> As a typical Mac user I expect that something has appeared in 
> /Applications. I see no matplotlib but at least there is a Python 2.7 
> folder. I click on "Python Launcher" which seems like the obvious 
> place to start. Nothing happens - oh wait, something has started but 
> it doesn't do much. I click on IDLE and this looks more promising. At 
> least there is a prompt that looks like the examples on the net. 
> Alternatively I have somehow found out how to run Python in the Terminal.
>
> Next issue... I type "import matplotlib" and up comes "ImportError: No 
> module named numpy". A search reveals www.numpy.org 
> <http://www.numpy.org>. I click on "Getting NumPy" and end up at the 
> SciPy installation page <http://www.scipy.org/install.html>. It 
> mentions Mac packages but only give an example for using Macports. 
> Otherwise it suggests installing a full Python distribution (What, 
> start from scratch? But I'm so close!).
>
> Argh, this is becoming a PITA. [At this stage Justin might 
> accidentally install a compiler and enter a new world of hurt :-)] Oh 
> well, the interwebs to the rescue. Search for "numpy mac". The first 
> hit is the aforementioned page. The second hit 
> <http://stackoverflow.com/questions/7338051/install-numpy-on-mac-os-x-lion-10-7> 
> looks more promising, but contains many conflicting answers ("Lion 
> comes with numpy installed?"). If I'm lucky I might follow the last 
> suggestion which reveals the NumPy SourceForge 
> <http://sourceforge.net/projects/numpy/files/NumPy/> page. Or I could 
> read the Numpy User Guide (DRAFT) -> Building and installing NumPy -> 
> Mac OS X which points there too.
>
> I assume I want the latest version (1.7.1) and I stumble upon 
> numpy-1.7.1-py2.7-python.org-macosx10.6.dmg. Hey, that has a familiar 
> and comforting filename! It installs without a hitch and finally 
> "import matplotlib" succeeds and I manage to make a plot from IDLE!
>
> Now I need a drink...
>
> <END EXPERIMENT>
>
> This was quite an eye-opener for me (although I wish I could shut my 
> eyes again quickly and forget this ever happened :-)). Hopefully the 
> typical would-be matplotlib user is not as hapless as Justin, but I 
> suspect that quite a few need guidance. I guess their best chance for 
> happiness is to stumble upon a full-fledged Python distribution but if 
> matplotlib is their entry point to the Python universe they might be 
> in for an adventure ride. Although if I had read the proper matplotlib 
> installation instructions first I might have gone straight to EPD...
>
> I picture the following basic Mac user groups:
>
> - Black belt: pulls git repositories to get bleeding-edge packages, 
> compiles from scratch, lives in the Terminal, probably uses Homebrew 
> Python or EPD / Anaconda or some custom Python installation
> - Savvy: likes to install packages via pip / easy_install, probably 
> has a compiler, not afraid of Terminal, probably uses Homebrew Python 
> or EPD / Anaconda or maybe even Macports / Fink Python
> - No Fuss: likes to click on a dmg, has no compiler, rarely uses 
> Terminal, possibly has EPD / Anaconda or just system Python
> - Justin: a hapless version of No Fuss :-)
>
> The problem I see with the binary dmg installer is that it is 
> currently aimed somewhere between Savvy and No Fuss users. It won't 
> help the Black Belt and EPD / Anaconda users and is also not as 
> straightforward as the No Fuss user would have hoped.
>
> This is why I'm wondering whether it would make more sense to base the 
> dmg installer on system Python instead. Since Lion ships with Python 
> 2.7.1, NumPy 1.5.1, libfreetype and libpng, OS X has had the potential 
> since 10.7 to run matplotlib out of the box with no modifications or 
> extra dependencies (although the latest 1.3.0 might throw a spanner in 
> the works again by shedding dateutil, pytz and friends). A No Fuss 
> user like Justin could therefore click on the dmg as he does with all 
> his other software installations and matplotlib will "just work" like 
> the OS X mantra says. Having used system Python extensively for many 
> years I can vouch that it is more than adequate for someone wanting to 
> try out matplotlib and sure is easier to install!
>
> Of course, maintaining the dmg installer is already a big job and your 
> work load is therefore probably the biggest factor in these 
> discussions :-)
>
> Best regards,
> Ludwig
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Oops, 
I noticed that my lengthy previous email lost the quotes around Russell's comment at the start. It should begin with:
> Is it useful in the long term to have such a packager? My impression is
> that as soon as packaging is more robust we'll switch to using pip or
> easy_install.
Hope that's less confusing...
L.

Sounds like a good idea to me.
In terms of when - I think the IPython guys have picked a good time (10am
US Pacific time, or 5pm GMT/UTC) to have the meeting to maximise the
attendance from the Americas and Europe, though I appreciate that no time
is perfect for everybody. For instance, I know Eric being in Hawaii–Aleutian
Time Zone that time would mean a 7am start, and for JJ, should he wish to
join in, it would be a 2am meeting... (for a clock of the places that may
need consideration see
http://www.timeanddate.com/worldclock/converted.html?iso=20130802T17&p1=0&p2=1358&p3=235&p4=263&p5=137&p6=103
).
Did you want to put a date on it Mike? How about we go for a week on
Tuesday, say the 2013年08月13日 17:00Z (in your time: http://goo.gl/OnWHBq) -
though I'm open to moving it, if that doesn't fit with some of the core
contributors who would like to attend. If anybody who knows they would like
to attend could notify us here (along with their time zone), we could also
try to optimise the time to reduce unsociable hours :-) though we have to
acknowledge that there is no such thing as the perfect time...
Cheers,
On 1 August 2013 19:58, Michael Droettboom <md...@st...> wrote:
>
> (Apologies for cross-posting).
>
> matplotlib has a dire need to improve its continuous integration
> testing. I've drafted MEP19 and solicited comments, but there hasn't
> been a lot of feedback thus far.
>
> As an alternative to mailing list discussion, where this sort of upfront
> planning can sometimes be difficult, I'm considering holding a Google
> Hangout in the next few weeks on the subject. It's ok to participate
> even if you don't have the time to work on matplotlib -- I would also
> like feedback from advice from those that have configured similar
> systems for other projects. matplotlib's needs are somewhat more
> complex in terms of dependencies, cpu, ram and storage, so we're pushing
> things pretty far here.
>
> If there's enough people with an interest in participating in the
> discussion, I'll send around a Doodle poll to find a good time.
>
> Mike
>
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

 Hi Russell (and Mike),
Is it useful in the long term to have such a packager? My impression is
that as soon as packaging is more robust we'll switch to using pip or
easy_install.
First off, sorry for the long email - got a bit carried away :-) The
summary is that I propose we keep the dmg installer but maybe make it use
the system Python for reasons illustrated below.
For the record, I'm using pip / easy_install to install matplotlib from
source on my Mac and that has been working fine for a while now. You only
need to add pkg-config (and the development tools, obviously) to a virgin
Mac system and this is now really easy in the days of Homebrew.
Of course, binary packages have the extra issue of a dependency on the
environment for which it is built, which complicates matters for binary
eggs (thanks for the reminder of wheel, Mike - definitely something to
watch). This is the main reason why I don't use the Mac installer dmg: it's
built for python.org Python and I prefer to use system Python instead.
(On this note, it would be interesting to find out how matplotlib people
get Python on their Mac these days. My gut feel tells me that Homebrew
Python will be quite popular these days, followed by EPD / Anaconda and
then maybe python.org Python. If you use Homebrew there is now the option
of "brew install matplotlib" courtesy of Samuel
John<https://github.com/samueljohn/homebrew-python/blob/master/matplotlib.rb>,
while EPD and Anaconda ship with their own versions of matplotlib, so most
of those users are taken care of.)
To answer your original question: I do see a use for a dmg installer in the
long term, but one you might not have considered. I picture a Mac user who
is not familiar with Python but wants to try out matplotlib (the image of
Justin Long saying "Hello, I'm a Mac" somehow comes to mind :-)).
Justin has never heard of easy_install or even a compiler and might not be
that comfortable with the Terminal. On the other hand, he is used to
installing software by downloading and clicking on a dmg or via the App
Store. This is a person who is starting out with these tools and needs as
few obstacles as possible to get going. Once he is up and running and likes
what he sees, he might be persuaded to install a more full-fledged Python
distribution or the rest of the SciPy stack.
As an experiment I put myself in the shoes of Justin. I actually did the
steps below on a spare MacBook Pro running Mac OS X 10.7.5 that was
unsullied by extra Pythons and rogue matplotlibs and what not.
<BEGIN EXPERIMENT>
Someone told me about "matplotlib" (maybe after seeing a plot in a talk or
a paper) which led me to matplotlib.org (first Google hit).
I see "Download" and go to the downloads
page<http://matplotlib.org/downloads.html>.
I see a bunch of links, including these two under "Latest stable version":
matplotlib-1.2.1-py2.7-python.org-macosx10.3.dmg
matplotlib-1.2.1-py2.7-python.org-macosx10.6.dmg
Since I am on Lion I guess I have to download the latter (although the fact
that it says 10.6 and not 10.7 worries me...). I'm not sure what the rest of
the filename means - what is py27-python.org? I download the dmg and open
it. I am impatient like most users and click on "Continue".
Oops, there is a problem. The third "Continue" button is grayed out with an
error that says: "matplotlib 1.2.1 can't be installed on this disk.
matplotlib requires System Python 2.7 to install." [This is ironic because,
unbeknownst to Justin, he actually *has* System Python 2.7 installed...] Time
to click on "Go Back"... Aah, Important Information (I kick myself for not
reading this): "matplotlib for MacOS X 10.6 or later [cool!] and 64-bit
Python 2.7 from python.org (not Apple's built-in Python)". So that's
probably what py2.7-python.org refers to. If Justin is patient enough he
might also spot the following line: "Before running matplotlib, you must
install numpy."
[Clicking "Go Back" would have been the more useful thing to do in this
case. If I had decided to return to matplotlib.org, I might have seen "Need
help?" and clicked on the "faq" link and ended up at the OS-X
Notes<http://matplotlib.org/1.3.0/faq/installing_faq.html#os-x-notes>.
This mentions "several alternative versions of python" such as EPD,
MacPython (yikes, Leopard only!) or python.org. But the installer only
works with the latter... Surprisingly enough I could not find *any* explicit
mention in the matplotlib installation docs that you need to install NumPy
first. EDIT: Oh wait, it's well documented
here<http://matplotlib.org/users/installing.html> but
I can only reach this important page by clicking on "docs" in the toolbar
below the page title and spotting the "Installing" link. Maybe the
"Download" section on the front page should read "Read the installation
instructions <http://matplotlib.org/users/installing.html> first and then
visit the matplotlib downloads page <http://matplotlib.org/downloads.html>
."]
Time to visit python.org. I see "Download" and then notice "Python 2.7.5
Mac OS X 64-bit/32-bit x86-64/i386 Installer (for Mac OS X 10.6 and later
[2])". I download the dmg and click on it. The installation is successful.
I go back to the matplotlib dmg and retry the installation - success!
Mmm, what now?
[This is not really matplotlib's problem, but I found surprisingly few
resources that tell you how to start Python on the Mac if you know
absolutely nothing about Unix and Terminals and such. If you search for
"python mac" on Google you at least get some idea at the first
hit<http://www.python.org/getit/mac/>.
The official Mac usage page <http://docs.python.org/2/using/mac.html> is
quite technical but mentions that "your best way to get started with Python
on Mac OS X is through the IDLE integrated development environment" which
at least gets you to a Python prompt.]
As a typical Mac user I expect that something has appeared in
/Applications. I see no matplotlib but at least there is a Python 2.7
folder. I click on "Python Launcher" which seems like the obvious place to
start. Nothing happens - oh wait, something has started but it doesn't do
much. I click on IDLE and this looks more promising. At least there is a
prompt that looks like the examples on the net. Alternatively I have
somehow found out how to run Python in the Terminal.
Next issue... I type "import matplotlib" and up comes "ImportError: No
module named numpy". A search reveals www.numpy.org. I click on "Getting
NumPy" and end up at the SciPy installation
page<http://www.scipy.org/install.html>.
It mentions Mac packages but only give an example for using Macports.
Otherwise it suggests installing a full Python distribution (What, start
from scratch? But I'm so close!).
Argh, this is becoming a PITA. [At this stage Justin might accidentally
install a compiler and enter a new world of hurt :-)] Oh well, the
interwebs to the rescue. Search for "numpy mac". The first hit is the
aforementioned page. The second
hit<http://stackoverflow.com/questions/7338051/install-numpy-on-mac-os-x-lion-10-7>looks
more promising, but contains many conflicting answers ("Lion comes
with numpy installed?"). If I'm lucky I might follow the last suggestion
which reveals the NumPy
SourceForge<http://sourceforge.net/projects/numpy/files/NumPy/>page.
Or I could read the Numpy User Guide (DRAFT) -> Building and
installing NumPy -> Mac OS X which points there too.
I assume I want the latest version (1.7.1) and I stumble upon
numpy-1.7.1-py2.7-python.org-macosx10.6.dmg. Hey, that has a familiar and
comforting filename! It installs without a hitch and finally "import
matplotlib" succeeds and I manage to make a plot from IDLE!
Now I need a drink...
<END EXPERIMENT>
This was quite an eye-opener for me (although I wish I could shut my eyes
again quickly and forget this ever happened :-)). Hopefully the typical
would-be matplotlib user is not as hapless as Justin, but I suspect that
quite a few need guidance. I guess their best chance for happiness is to
stumble upon a full-fledged Python distribution but if matplotlib is their
entry point to the Python universe they might be in for an adventure ride.
Although if I had read the proper matplotlib installation instructions
first I might have gone straight to EPD...
I picture the following basic Mac user groups:
- Black belt: pulls git repositories to get bleeding-edge packages,
compiles from scratch, lives in the Terminal, probably uses Homebrew Python
or EPD / Anaconda or some custom Python installation
- Savvy: likes to install packages via pip / easy_install, probably has a
compiler, not afraid of Terminal, probably uses Homebrew Python or EPD /
Anaconda or maybe even Macports / Fink Python
- No Fuss: likes to click on a dmg, has no compiler, rarely uses Terminal,
possibly has EPD / Anaconda or just system Python
- Justin: a hapless version of No Fuss :-)
The problem I see with the binary dmg installer is that it is currently
aimed somewhere between Savvy and No Fuss users. It won't help the Black
Belt and EPD / Anaconda users and is also not as straightforward as the No
Fuss user would have hoped.
This is why I'm wondering whether it would make more sense to base the dmg
installer on system Python instead. Since Lion ships with Python 2.7.1,
NumPy 1.5.1, libfreetype and libpng, OS X has had the potential since 10.7
to run matplotlib out of the box with no modifications or extra
dependencies (although the latest 1.3.0 might throw a spanner in the works
again by shedding dateutil, pytz and friends). A No Fuss user like Justin
could therefore click on the dmg as he does with all his other software
installations and matplotlib will "just work" like the OS X mantra says.
Having used system Python extensively for many years I can vouch that it is
more than adequate for someone wanting to try out matplotlib and sure is
easier to install!
Of course, maintaining the dmg installer is already a big job and your work
load is therefore probably the biggest factor in these discussions :-)
Best regards,
Ludwig

On 2013年08月01日 10:40 AM, Matt Terry wrote:
> Hi,
> I'm working on cleaning up the key-event callback code. What is the
> correct spelling of the control key? Is it "control" or "ctrl"?
> Different backends spell it differently. May I homogenize things at the
> expense of breaking code? Fwiw, the qt4 backend spells it both ways
> depending on the code path.
>
> -matt
Matt,
http://matplotlib.org/api/backend_bases_api.html#matplotlib.backend_bases.KeyEvent
It looks like the key is "control" but the modifier is "ctrl".
Eric

Hi,
I'm working on cleaning up the key-event callback code. What is the correct
spelling of the control key? Is it "control" or "ctrl"? Different backends
spell it differently. May I homogenize things at the expense of breaking
code? Fwiw, the qt4 backend spells it both ways depending on the code path.
-matt

(Apologies for cross-posting).
matplotlib has a dire need to improve its continuous integration
testing. I've drafted MEP19 and solicited comments, but there hasn't
been a lot of feedback thus far.
As an alternative to mailing list discussion, where this sort of upfront
planning can sometimes be difficult, I'm considering holding a Google
Hangout in the next few weeks on the subject. It's ok to participate
even if you don't have the time to work on matplotlib -- I would also
like feedback from advice from those that have configured similar
systems for other projects. matplotlib's needs are somewhat more
complex in terms of dependencies, cpu, ram and storage, so we're pushing
things pretty far here.
If there's enough people with an interest in participating in the
discussion, I'll send around a Doodle poll to find a good time.
Mike

(Apologies for cross-posting).
matplotlib has a dire need to improve its continuous integration 
testing. I've drafted MEP19 and solicited comments, but there hasn't 
been a lot of feedback thus far.
As an alternative to mailing list discussion, where this sort of upfront 
planning can sometimes be difficult, I'm considering holding a Google 
Hangout in the next few weeks on the subject. It's ok to participate 
even if you don't have the time to work on matplotlib -- I would also 
like feedback from advice from those that have configured similar 
systems for other projects. matplotlib's needs are somewhat more 
complex in terms of dependencies, cpu, ram and storage, so we're pushing 
things pretty far here.
If there's enough people with an interest in participating in the 
discussion, I'll send around a Doodle poll to find a good time.
Mike