matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Py3 merge

[Arik R. F. <ari...@es...>]

Hi Mike,

I managed to get matplotlib to compile and run on Python 3.2.2 on 
Windows though at present there are two problems:

1. The linker is missing the "/MANIFEST" argument. This means that the 
manifest files are not being created and somehow the module does not 
link the dependencies properly. (Resulting in the problem I described in 
my email earlier today.) Also linking breaks due to the missing manifest 
files.

I found that a (probably too specific) fix is to modify the function 
"make_extension" in setupext.py: Changing the first line of the function to:
ext = Extension(*args, extra_link_args=['/MANIFEST'], **kwargs)

I am sure however that the extra arguments must be set depending on the 
compiler chosen - though I do not quite follow the workflow of setup.py...


2. The file containing the visual studio static dependencies 
(http://matplotlib.sourceforge.net/win32_static_vs.tar.gz) still has the 
old tk and tcl versions. It would suffice to add tk85.lib and tcl85.lib 
from a Python3 installation to the package.

Also, the existence of this package is very poorly advertised. It seems 
to be mentionned only in the code of setupext.py. The wiki-page 
http://matplotlib.sourceforge.net/users/installing.html makes no mention 
of it in the setion "Installing from source". It suggests that it is 
necessary to build each of the dependencies oneself.

Apart from this, on the face of it matplotlib seems to work fine on 
Python 3.2.2 on Windows.

Many thanks!!!
Arik


On 09/11/2011 18:24, Michael Droettboom wrote:
 > I just pressed the big green merge button...  :)
 >
 > Master should now have all of the Python 3 portability changes.  It's
 > passing all tests, and running all examples, but I still wouldn't be
 > surprised if some things broke in the process.  Please kick the tires
 > and report bugs.  It would be helpful in the bug reports to know whether
 > the bug is only on Python 2 or 3 or both, and whether it is a regression
 > from matplotlib 1.1.x.
 >
 > Cheers,
 > Mike
 >
 > 
------------------------------------------------------------------------------
 > RSA(R) Conference 2012
 > Save $700 by Nov 18
 > Register now
 > http://p.sf.net/sfu/rsa-sfdev2dev1



-- 
Arik FUNKE
Institut Langevin
ESPCI ParisTech, CNRS UMR 7587, UPMC, UDD, INSERM
10 rue Vauquelin, 75231 PARIS Cedex 05, FRANCE
Tel:  +33 1 40 79 45 91; Fax:   +33 1 40 79 45 37
E-mail: ari...@es...

[matplotlib-devel] Py3 merge

[Michael D. <md...@st...>]

I just pressed the big green merge button...  :)

Master should now have all of the Python 3 portability changes.  It's 
passing all tests, and running all examples, but I still wouldn't be 
surprised if some things broke in the process.  Please kick the tires 
and report bugs.  It would be helpful in the bug reports to know whether 
the bug is only on Python 2 or 3 or both, and whether it is a regression 
from matplotlib 1.1.x.

Cheers,
Mike

[matplotlib-devel] Statically linking matplotlib-py3k on Windows

[Arik R. F. <ari...@es...>]

Hello

I have been trying to use the py3k branch but I am having some problems 
I am hoping somebody could help me with; more specifically I am looking 
for a way to statically link matplotlib.

Using
- VC 2010
- python 3.2.2
- the static linking libraries / header files for matplotlib
I have managed to get the py3k branch to build and install.

Unfortunately when I do "import pylab", python complains about missing 
dlls (for each of its dependencies, zlib, freetype, ...). Is there a way 
to link the libraries statically? I would really love to avoid having to 
juggle with dlls.

Many thanks.

Regards,
Arik

PS: As a side note, while building I am getting a lot of errors of the type:
build\temp.win32-3.2\Release\src\ft2font.pyd.manifest : general error 
c1010070: Failed to load and parse the manifest. error: command 'mt.exe' 
failed with exit status 31

I managed to get rid of these by manually creating empty .manifest files 
though I am not sure what effect this might have and whether there is an 
easier way.


-- 
Arik FUNKE
Institut Langevin
ESPCI ParisTech, CNRS UMR 7587, UPMC, UDD, INSERM
10 rue Vauquelin, 75231 PARIS Cedex 05, FRANCE
Tel:  +33 1 40 79 45 91; Fax:   +33 1 40 79 45 37
E-mail: ari...@es...

Re: [matplotlib-devel] How do you use numpy.ma?

[Benjamin R. <ben...@ou...>]

On Sun, Nov 6, 2011 at 4:43 PM, Nathaniel Smith <nj...@po...> wrote:

> Hi matplotters,
>
> As any of you subscribed to the numpy-discussion list will have
> probably noticed, there's intense debate going on about how numpy can
> do a better job of handling missing data and masked arrays. Part of
> the problem is that we aren't actually sure what users need these
> features to do. There's one group who just wants R-style "missing
> data", and their needs are pretty straightforward -- they just want a
> magic value that indicates some data point doesn't actually exist. But
> it seems like there's also demand for a more "masked array"-like
> feature, similar to the current numpy.ma, where the mask is
> non-destructive and easily manipulable. No-one seems clear on who
> exactly this should work, though, and there's a lot of disagreement
> about what semantics make sense. (If you want more details, there's a
> wiki page summarizing some of this[1]).
>
> Since you seem to be the biggest users of numpy.ma, it would be really
> helpful if you could explain how you actually use it, so we can make
> sure that whatever we do in numpy-land is actually useful to you!
>
> What does matplotlib use masked arrays for? Is it just a convenient
> way to keep an array and a boolean mask together in one object, or do
> you take advantage of more numpy.ma features? For example, do you
> ever:
>  - unmask values?
>  - create multiple arrays that share the same storage for their data,
> but have different masks? (i.e., creating a new array with new
> elements masked, but without actually allocating the memory for a full
> array copy)
>  - use reduction operations on masked arrays? (e.g., np.sum(masked_arr))
>  - use binary operations on masked arrays? (e.g., masked_arr1 +
> masked_arr2)
>
> And while we're at it, any complaints about how numpy.ma works now,
> that a new version might do better?
>
> Thanks in advance,
> -- Nathaniel
>
> [1] https://github.com/njsmith/numpy/wiki/NA-discussion-status
>
>
Hi Nathaniel,

Unfortunately, I can't spend much more time on this topic due to my
dissertation work.  I will allow others to elaborate further, if they wish.
But I think I can summarize it a bit.

First, we try our best to respect multiple ways of users specifying missing
data as input to our main plotting functions. Most common are NaNs and
np.mamasks.  Given that we try to maintain compatibility with older
versions of
Numpy, we are going to have to build some sort of compatibility mechanism
to unify any representation (NaNs, np.ma, NA(or whatever it will be
called)) under a single abstraction to be used internally. This will
probably be np.ma at first until we can depend on the existence of np.NA.

Second, with functions that have multiple input arrays (pretty much all of
them), a single mask has to be applied to all data (typically a
logical_or'ing of the individual masks). Some other functions such as the
pcolor family of functions have slightly more complicated mask merging.

The most important thing is that we do not modify the user's data, and we
keep copies to a minimum. np.ma works great because we can convert the
arrays into masked_arrays without a copy, and the mask-merging process does
not modify the user's input data. I don't think we were using some of the
more advanced features of np.ma, but I can't be sure of that.

I guess the tricky thing that could occur (and probably should be tested
for) is if the input array is already a masked array and that we aren't
changing the user's pre-existing masks.

Ben Root

[matplotlib-devel] How do you use numpy.ma?

[Nathaniel S. <nj...@po...>]

Hi matplotters,

As any of you subscribed to the numpy-discussion list will have
probably noticed, there's intense debate going on about how numpy can
do a better job of handling missing data and masked arrays. Part of
the problem is that we aren't actually sure what users need these
features to do. There's one group who just wants R-style "missing
data", and their needs are pretty straightforward -- they just want a
magic value that indicates some data point doesn't actually exist. But
it seems like there's also demand for a more "masked array"-like
feature, similar to the current numpy.ma, where the mask is
non-destructive and easily manipulable. No-one seems clear on who
exactly this should work, though, and there's a lot of disagreement
about what semantics make sense. (If you want more details, there's a
wiki page summarizing some of this[1]).

Since you seem to be the biggest users of numpy.ma, it would be really
helpful if you could explain how you actually use it, so we can make
sure that whatever we do in numpy-land is actually useful to you!

What does matplotlib use masked arrays for? Is it just a convenient
way to keep an array and a boolean mask together in one object, or do
you take advantage of more numpy.ma features? For example, do you
ever:
 - unmask values?
 - create multiple arrays that share the same storage for their data,
but have different masks? (i.e., creating a new array with new
elements masked, but without actually allocating the memory for a full
array copy)
 - use reduction operations on masked arrays? (e.g., np.sum(masked_arr))
 - use binary operations on masked arrays? (e.g., masked_arr1 + masked_arr2)

And while we're at it, any complaints about how numpy.ma works now,
that a new version might do better?

Thanks in advance,
-- Nathaniel

[1] https://github.com/njsmith/numpy/wiki/NA-discussion-status

[matplotlib-devel] tagging releases (v1.1.0 tag missing)

[Paul I. <piv...@gm...>]

Hey gang,

as per this discussion:

On Thu, Nov 3, 2011 at 3:40 AM, John Hunter <jd...@gm...> wrote:
> On Nov 2, 2011, at 10:47 PM, Benjamin Root <ben...@ou...> wrote:
>
> So the instruction should be to remind John Hunter to update the entry in
> PyPi? Got it.
>
>
> Even better, it should be:
> 1) update the release notes in the devel docs
> 2) give Ben access to the pypi acct.

I added a note to the release docs about tagging the releases - right
now, there's no clear way inside git to know what ended up in v1.1.0
final, without grabbing a tarball and poking around. I'm inlining the
relevant part of that commit here, so that John/Ben can tag the
release after the fact.

---
For each release candidate as well as for the final release version,
please `git tag` the commit you will use for packaging like so::

    git tag -a v1.1.0rc1

The `-a` flag will allow you to write a message about the tag, and
affiliate your name with it. A reasonable tag message would be something
like ``v1.1.0 Release Candidate 1 (September 24, 2011)``. To tag a
release after the fact, just track down the commit hash, and::

    git tag -a v1.0.1 a9f3f3a50745

Tags allow developers to quickly checkout different releases by name,
and also provides source download via zip and tarball on github.
---

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Re: [matplotlib-devel] matplotlib.pyplot.imsave bug

[Michael D. <md...@st...>]

What version of matplotlib are you using?  This appears to be fixed in 
the latest 1.1.  If you can let me know what version you're using, 
perhaps it will be easy to provide a patch if you're not able to upgrade 
wholesale.

Mike

On 10/31/2011 11:53 AM, Rachel Anderson wrote:
> Hello,
>
> I've noticed a bug with matplotlib.pyplot.imsave.  Say I have an array 
> that is 1000*1000.  This works perfectly:
>
> pylab.imsave(outfile,data,format='png',origin='lower')
>
> and I get image1.png.
>
> However, if the array is not a square, say 1000*1500, then the output 
> image is rotated 90 degrees compared to the image it prints out. 
>  Example, image2.png.
>
> I tried numpy.rot90(frame) to rotate my data, and though my data did 
> rotate, so did the output frame.  Example, image3.png.
>
> If there is a way around this, please let me know.  Otherwise, it 
> should be fixed  ;)
>
> Cheers,
> Rachel
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

[matplotlib-devel] matplotlib.pyplot.imsave bug

[Rachel A. <ra...@st...>]

Hello,

I've noticed a bug with matplotlib.pyplot.imsave.  Say I have an array that is 1000*1000.  This works perfectly:

pylab.imsave(outfile,data,format='png',origin='lower')

and I get image1.png.

However, if the array is not a square, say 1000*1500, then the output image is rotated 90 degrees compared to the image it prints out.  Example, image2.png.

I tried numpy.rot90(frame) to rotate my data, and though my data did rotate, so did the output frame.  Example, image3.png.

If there is a way around this, please let me know.  Otherwise, it should be fixed  ;)

Cheers,
Rachel

Re: [matplotlib-devel] Merging Python 3 branch?

[Michael D. <md...@st...>]

BTW -- the diff is so large that viewing this page crashes my browser 
tab (in Chrome).  YMMV.  You can view the diff locally by first getting 
my repository:

    git remote add mdboom git://github.com/mdboom/matplotlib.git
    git fetch mdboom

then diffing with an external tool:

    git diff --ext-diff upstream/master mdboom/py3-merge

Of course, we can't use github's code review features that way :(

Mike


On 10/31/2011 09:16 AM, Michael Droettboom wrote:
> The pull request to merge the py3 fork back into matplotlib/master is 
> here:
>
> https://github.com/matplotlib/matplotlib/pull/565
>
> Thanks to everyone who worked on it.
>
> I plan to leave this up for a while and get as much chance for review 
> as possible.
>
> Mike
>
> On 10/28/2011 01:50 PM, Michael Droettboom wrote:
>> Now that we have 1.1.0 out, I was thinking maybe now is the time to
>> merge the matplotlib-py3 branch into master.  As a reminder, the main
>> downside is losing compatibility with Python 2.5 and earlier.  We would
>> continue to have a 1.1.x maintenance branch for the foreseeable future
>> for small-yet-critical bugfixes, and can still make a Python
>> 2.5-compatible bugfix release from that.
>>
>> Any objections or concerns?  Any reason to hold off?
>>
>> Mike
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Merging Python 3 branch?

[Michael D. <md...@st...>]

The pull request to merge the py3 fork back into matplotlib/master is here:

https://github.com/matplotlib/matplotlib/pull/565

Thanks to everyone who worked on it.

I plan to leave this up for a while and get as much chance for review as 
possible.

Mike

On 10/28/2011 01:50 PM, Michael Droettboom wrote:
> Now that we have 1.1.0 out, I was thinking maybe now is the time to
> merge the matplotlib-py3 branch into master.  As a reminder, the main
> downside is losing compatibility with Python 2.5 and earlier.  We would
> continue to have a 1.1.x maintenance branch for the foreseeable future
> for small-yet-critical bugfixes, and can still make a Python
> 2.5-compatible bugfix release from that.
>
> Any objections or concerns?  Any reason to hold off?
>
> Mike
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Thoughts on more loosely coupling Axes objects from Figures

[Lee M. <lee...@gm...>]

I'm trying to develop some control-systems libraries and I would like to
add some functionality to give plots of transfer-function representations,
but I've run into a bit of a stumbling-block. For a given transfer
function, I would like to give a way of constructing a an Axes object to be
added into a figure. Normally, it would be just fine to send in an Axes
from the user, but I need a particular (Polar) projection, which can only
be specified at the Axes creation and requires suficient user knowledge to
do something that should be done by the library.

I could not find any way to construct my graph in a function exactly as it
should be represented and then return it for the user to add it into a
figure as a subplot. I could simply be going about this the wrong way, but
I've dug into the sources a bit and I see from the inheritance of the
Artist object that Axes is quite strongly tied into the figure that created
it. It seems that Matplotlib is particularly figure-centric. Now this is
great because it gives you very great tools such as sharex and sharey and
many of the layout options that exist, but for library development, I think
that an axes-centric approach is more useful (so that the user can decide
how to layout multiple graphs representing the library objects, some of
which may need particular labeling and projection settings).

I wanted to see what others thought about this and some options to help
this situation (and to see if others think this is a big issue at all).

Changing Axes itself seems too large a task since it would break API
compatibility, but perhaps there could be ways of importing
already-constructed Axes into a figure. Here are some options:

1) allow the add_subplot and add_axes kwarg 'axes=' to accept any axis,
which it then imports into the figure (possibly creating deep copies of the
Projections and Labels and such)

2) Make new Axes-like (but non-Artist) objects for the user to use (very
similar interface). These would register to figure-aware Axes (possibly
many of them) and propagate plotting function calls down to the Axes. They
would remember the high-level plotting calls that were used on them so that
future registrations of Artist-Axes would reflect everything. this is the
most invasive, yet natural solution to me, but relegates the current
incarnation of Axes into being "back-end" objects.

3) Make Axes its own object and make it use draw calls that take an Artist
to draw high-level plotting functions. This leaves it completely decoupled,
but is likely infeasible.

Please let me know what you think. If there is a clear direction on this,
I'll commit some time to a fix, but I'm not so familiar with the ins and
outs of the code yet.

Lee

Re: [matplotlib-devel] Sankey documentation missing in v1.1?

[Benjamin R. <ben...@ou...>]

On Sunday, October 30, 2011, Kevin Davies <kda...@gm...> wrote:
> Hello,
>
> I don't think the web documentation is showing up for the new Sankey
diagram class.  I probably failed to hook it in somehow.  Could someone
please take a look?
>
> The file that would have produced the documentation is
matplotlib/lib/matplotlib/sankey.py.  I expected it would show up at
> http://matplotlib.sourceforge.net/api/sankey_api.html, but there's no
such page.
>
> The Sankey demos did show up on the examples page and in the gallery.
Also, the overview showed up in the "what's new" page.
>
> Thanks.
>
> Kevin
>

Whoops.  I knew I forgot something.  API docs are generated from adding a
file to doc/api.  I will upload a patch soon.

Ben

Re: [matplotlib-devel] Keybinding doc & close window

[Antoine L. <ant...@gm...>]

30/10/11 00:27, John Hunter
> On Sat, Oct 29, 2011 at 2:52 PM, Antoine Levitt
> <ant...@gm...> wrote:
>> Just typing f = gcf() displays a figure, which I don't want to do. I
>> want to be able to put something in my ipython init file that'd set my
>> bindings, without changing anything else.
>
> This is a reasonable request, though there are some implementation
> details to sort through.  For one, the rc file format is very simple,
> and not amenable to putting in multil-ine functions.  But you could
> write something like
>
>   keybinding.q  : lambda event: plt.close(event.canvas.figure)
>
> Eg, when a key is pressed for which you have associated a lambda, we
> could call your lambda with the event that triggered, and you can
> access attributes like canvas.figure to operate on them.  We could
> eval your lambda in the pyplot namespace.  But more sophisticated
> functions would be difficult to expose given the simplicity of rc
> format.

I was thinking of ipython_config.py, which is full python. Then, add a
hook for a function to be run whenever a figure is created. I don't know
if I can access the matplotlib stuff from ipython_config.py though. I'll
take a look.

Just curious: what's the point of having a specific rc format, instead
of just running python code and defining a few special functions to make
it easier to write a config file? If you want to keep the rc format, why
not add a command to run a python file?

>
> If you are interested in taking a crack at this Antoine, we'd be happy
> to evaluate a pull request.  If not, perhaps I or one of the other
> developers can take a look.

I'll take a look and report back.

>
> Note that in most windowing systems, it is fairly easy to bind a
> keystroke to close a window, so you could get the effect of 'q' w/o
> modifying MPL, though you might need a two keystroke binding,

Defining "q" to mean "quit this window" for every window might be a
little problematic. :-) There's always alt+f4, but I find it a little
bothersome, "q" is much simpler.

Re: [matplotlib-devel] Keybinding doc & close window

[John H. <jd...@gm...>]

On Sat, Oct 29, 2011 at 2:52 PM, Antoine Levitt
<ant...@gm...> wrote:
> Just typing f = gcf() displays a figure, which I don't want to do. I
> want to be able to put something in my ipython init file that'd set my
> bindings, without changing anything else.

This is a reasonable request, though there are some implementation
details to sort through.  For one, the rc file format is very simple,
and not amenable to putting in multil-ine functions.  But you could
write something like

  keybinding.q  : lambda event: plt.close(event.canvas.figure)

Eg, when a key is pressed for which you have associated a lambda, we
could call your lambda with the event that triggered, and you can
access attributes like canvas.figure to operate on them.  We could
eval your lambda in the pyplot namespace.  But more sophisticated
functions would be difficult to expose given the simplicity of rc
format.

If you are interested in taking a crack at this Antoine, we'd be happy
to evaluate a pull request.  If not, perhaps I or one of the other
developers can take a look.

Note that in most windowing systems, it is fairly easy to bind a
keystroke to close a window, so you could get the effect of 'q' w/o
modifying MPL, though you might need a two keystroke binding,

Re: [matplotlib-devel] Keybinding doc & close window

[Antoine L. <ant...@gm...>]

29/10/11 21:50, Benjamin Root
> On Saturday, October 29, 2011, Antoine Levitt
> <ant...@gm...> wrote:
>> 29/10/11 21:20, Benjamin Root
>>> On Saturday, October 29, 2011, Antoine Levitt
>>> <ant...@gm...> wrote:
>>>> 29/10/11 19:39, Benjamin Root
>>>>> I don't think there is a document for the default keymaps, and
>>> there
>>>>> has been some talk about redoing default keybindings, because
> they
>>> are
>>>>> so hidden and varies from backend to backend.
>>>>>
>>>>> In the meantime, I would suggest checking out the "event
> handeling"
>>>>> section of the examples page. You can have a function that you
>>> attach
>>>>> to the "key_press_event", which takes an "event" object as an
>>>>> argument.  That event object has the key that was pressed.  You
> can
>>>>> then have an if...elif...else statement for all the keys and
>>> actions,
>>>>> or have a dictionary of key-action pairs.
>>>>>
>>>>> Hope that helps!
>>>>> Ben Root
>>>>
>>>> That's pretty cool! However, I have to do it for every figure I
>>> create,
>>>> there doesn't seem to be a way to tell matplotlib : "whenever a
>>> figure
>>>> is created, associate this handler to this event".
>>>>
>>>> I think I'll just wait for the keybinding stuff to get refactored,
>>> which
>>>> would definitely be a good idea (I only found out via very
> indirect
>>>> means, and had to change backend to get them working). It seems
>>>> worthwhile to have a "q" default binding to exit the plot.
>>>>
>>>
>>> The basic event handling isn't going to be refactored.  I was
> merely
>>> speaking of how the default keymaps are set.  Yes, you will need to
>>> mpl_connect for each figure object.  This is standard for any GUI
>>> control system.  What you can do is make a function that produces a
>>> figure for you as well as perform any event connections for you.
>>>
>>> Ben Root
>>
>> The problem is that I don't usually invoke figure(), I just do
>> plot(x,y), which will presumably call figure for me. So unless
> there's
>> some kind of event that's run after figure is called, I can't have a
>> generic way of adding my bindings.
>>
>
> Try
>
> gcf().canvas.mpl_connect(...)

Just typing f = gcf() displays a figure, which I don't want to do. I
want to be able to put something in my ipython init file that'd set my
bindings, without changing anything else.

Re: [matplotlib-devel] Keybinding doc & close window

[Benjamin R. <ben...@ou...>]

On Saturday, October 29, 2011, Antoine Levitt <ant...@gm...>
wrote:
> 29/10/11 21:20, Benjamin Root
>> On Saturday, October 29, 2011, Antoine Levitt
>> <ant...@gm...> wrote:
>>> 29/10/11 19:39, Benjamin Root
>>>> I don't think there is a document for the default keymaps, and
>> there
>>>> has been some talk about redoing default keybindings, because they
>> are
>>>> so hidden and varies from backend to backend.
>>>>
>>>> In the meantime, I would suggest checking out the "event handeling"
>>>> section of the examples page. You can have a function that you
>> attach
>>>> to the "key_press_event", which takes an "event" object as an
>>>> argument.  That event object has the key that was pressed.  You can
>>>> then have an if...elif...else statement for all the keys and
>> actions,
>>>> or have a dictionary of key-action pairs.
>>>>
>>>> Hope that helps!
>>>> Ben Root
>>>
>>> That's pretty cool! However, I have to do it for every figure I
>> create,
>>> there doesn't seem to be a way to tell matplotlib : "whenever a
>> figure
>>> is created, associate this handler to this event".
>>>
>>> I think I'll just wait for the keybinding stuff to get refactored,
>> which
>>> would definitely be a good idea (I only found out via very indirect
>>> means, and had to change backend to get them working). It seems
>>> worthwhile to have a "q" default binding to exit the plot.
>>>
>>
>> The basic event handling isn't going to be refactored.  I was merely
>> speaking of how the default keymaps are set.  Yes, you will need to
>> mpl_connect for each figure object.  This is standard for any GUI
>> control system.  What you can do is make a function that produces a
>> figure for you as well as perform any event connections for you.
>>
>> Ben Root
>
> The problem is that I don't usually invoke figure(), I just do
> plot(x,y), which will presumably call figure for me. So unless there's
> some kind of event that's run after figure is called, I can't have a
> generic way of adding my bindings.
>

Try

gcf().canvas.mpl_connect(...)

Before any show() calls or after any particular plotting commands.

Ben Root

Re: [matplotlib-devel] Keybinding doc & close window

[Antoine L. <ant...@gm...>]

29/10/11 21:20, Benjamin Root
> On Saturday, October 29, 2011, Antoine Levitt
> <ant...@gm...> wrote:
>> 29/10/11 19:39, Benjamin Root
>>> I don't think there is a document for the default keymaps, and
> there
>>> has been some talk about redoing default keybindings, because they
> are
>>> so hidden and varies from backend to backend.
>>>
>>> In the meantime, I would suggest checking out the "event handeling"
>>> section of the examples page. You can have a function that you
> attach
>>> to the "key_press_event", which takes an "event" object as an
>>> argument.  That event object has the key that was pressed.  You can
>>> then have an if...elif...else statement for all the keys and
> actions,
>>> or have a dictionary of key-action pairs.
>>>
>>> Hope that helps!
>>> Ben Root
>>
>> That's pretty cool! However, I have to do it for every figure I
> create,
>> there doesn't seem to be a way to tell matplotlib : "whenever a
> figure
>> is created, associate this handler to this event".
>>
>> I think I'll just wait for the keybinding stuff to get refactored,
> which
>> would definitely be a good idea (I only found out via very indirect
>> means, and had to change backend to get them working). It seems
>> worthwhile to have a "q" default binding to exit the plot.
>>
>
> The basic event handling isn't going to be refactored.  I was merely
> speaking of how the default keymaps are set.  Yes, you will need to
> mpl_connect for each figure object.  This is standard for any GUI
> control system.  What you can do is make a function that produces a
> figure for you as well as perform any event connections for you.
>
> Ben Root 

The problem is that I don't usually invoke figure(), I just do
plot(x,y), which will presumably call figure for me. So unless there's
some kind of event that's run after figure is called, I can't have a
generic way of adding my bindings.

Re: [matplotlib-devel] Keybinding doc & close window

[Benjamin R. <ben...@ou...>]

On Saturday, October 29, 2011, Antoine Levitt <ant...@gm...>
wrote:
> 29/10/11 19:39, Benjamin Root
>> I don't think there is a document for the default keymaps, and there
>> has been some talk about redoing default keybindings, because they are
>> so hidden and varies from backend to backend.
>>
>> In the meantime, I would suggest checking out the "event handeling"
>> section of the examples page. You can have a function that you attach
>> to the "key_press_event", which takes an "event" object as an
>> argument.  That event object has the key that was pressed.  You can
>> then have an if...elif...else statement for all the keys and actions,
>> or have a dictionary of key-action pairs.
>>
>> Hope that helps!
>> Ben Root
>
> That's pretty cool! However, I have to do it for every figure I create,
> there doesn't seem to be a way to tell matplotlib : "whenever a figure
> is created, associate this handler to this event".
>
> I think I'll just wait for the keybinding stuff to get refactored, which
> would definitely be a good idea (I only found out via very indirect
> means, and had to change backend to get them working). It seems
> worthwhile to have a "q" default binding to exit the plot.
>

The basic event handling isn't going to be refactored.  I was merely
speaking of how the default keymaps are set.  Yes, you will need to
mpl_connect for each figure object.  This is standard for any GUI control
system.  What you can do is make a function that produces a figure for you
as well as perform any event connections for you.

Ben Root

Re: [matplotlib-devel] Keybinding doc & close window

[Antoine L. <ant...@gm...>]

29/10/11 19:39, Benjamin Root
> I don't think there is a document for the default keymaps, and there
> has been some talk about redoing default keybindings, because they are
> so hidden and varies from backend to backend.
>
> In the meantime, I would suggest checking out the "event handeling"
> section of the examples page. You can have a function that you attach
> to the "key_press_event", which takes an "event" object as an
> argument.  That event object has the key that was pressed.  You can
> then have an if...elif...else statement for all the keys and actions,
> or have a dictionary of key-action pairs.
>
> Hope that helps!
> Ben Root

That's pretty cool! However, I have to do it for every figure I create,
there doesn't seem to be a way to tell matplotlib : "whenever a figure
is created, associate this handler to this event".

I think I'll just wait for the keybinding stuff to get refactored, which
would definitely be a good idea (I only found out via very indirect
means, and had to change backend to get them working). It seems
worthwhile to have a "q" default binding to exit the plot.

Re: [matplotlib-devel] Keybinding doc & close window

[Benjamin R. <ben...@ou...>]

On Saturday, October 29, 2011, Antoine Levitt <ant...@gm...>
wrote:
> Hi,
>
> Is there any doc of the various bindable actions? I only found
> http://matplotlib.sourceforge.net/users/customizing.html, and I'm not
> sure all of them are in there. In particular, I'd like a simple "q"
> keybinding to close the window, and ideally a way to run arbitrary
> python code.
>
> Antoine
>

I don't think there is a document for the default keymaps, and there has
been some talk about redoing default keybindings, because they are so hidden
and varies from backend to backend.

In the meantime, I would suggest checking out the "event handeling" section
of the examples page. You can have a function that you attach to the
"key_press_event", which takes an "event" object as an argument.  That event
object has the key that was pressed.  You can then have an if...elif...else
statement for all the keys and actions, or have a dictionary of key-action
pairs.

Hope that helps!
Ben Root

[matplotlib-devel] Keybinding doc & close window

[Antoine L. <ant...@gm...>]

Hi,

Is there any doc of the various bindable actions? I only found
http://matplotlib.sourceforge.net/users/customizing.html, and I'm not
sure all of them are in there. In particular, I'd like a simple "q"
keybinding to close the window, and ideally a way to run arbitrary
python code.

Antoine

[matplotlib-devel] Pyside 1.0.8 compatibility patch

[Trémouilles D. <dav...@gm...>]

Hello,

I've recently switched to PySide 1.0.8 on my MacBook using macports.
It seems that it breaks part of matplotlib.

Not sure if this is pyside or matplotlib bug but
the attached change in matplotlib solved the issue for me.

Regards,

David

Re: [matplotlib-devel] Merging Python 3 branch?

[Fernando P. <fpe...@gm...>]

Hey guys,

On Fri, Oct 28, 2011 at 11:41 AM, Eric Firing <ef...@ha...> wrote:
> 1) In the coding guide, it might be good to have notes (tips) about how
> to maintain compatibility, or at least references to such notes.  I have
> read about py3 but have never worked with it.

+1 for the py3 merge!  IPython master is already fully on py3 and we
should be releasing very soon 0.12 with this.  So once mpl is merged,
it will be possible to have from either releases or master, the full
'minimal stack' (numpy/scipy/mpl/sympy/cython/ipython) on py3, which I
think is awesome.

In case it's of any use to you guys, feel free to pillage our little
bag of utilities for py3 compatibility:

https://github.com/ipython/ipython/blob/master/IPython/utils/py3compat.py

By grepping the IPython sources for py3compat imports you can also see
how we use them, in case it helps.

Best,

f

ps - full credit on all this in IPython goes to @takluyver, who joined
the project initially just based on his need to have ipython on py3
and has turned out to be an all-around amazing member of the project.
I'm sure if you guys hit any bumps he'd be able to help out, as he
uses py3 regularly as his default platform and therefore knows quite a
bit about it.

Re: [matplotlib-devel] Merging Python 3 branch?

[Michael D. <md...@st...>]

Sorry for the double post.  Having trouble with my mail transport 
today.  The one with the later date is the "canonical reference".  :)

Re: [matplotlib-devel] Merging Python 3 branch?

[Eric F. <ef...@ha...>]

On 10/28/2011 09:00 AM, Michael Droettboom wrote:

>> 4) I hope the 1.1.x branch doesn't have to be maintained too long; or if
>> it does, it would be good to have a single designated maintainer to take
>> care of it, backporting from master or applying custom fixes as needed.
>>
> I feel like merging in the Python 3 changes is only an improvement in
> this respect.  Right now, I build/install/test three branches on a
> regular basis.  After the merge, we go down to two.

Absolutely!  Go for it!

Eric

>
> Mike