matplotlib-devel Mailing List for matplotlib

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

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

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

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

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

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.

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,

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.

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

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.

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

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.

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

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

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

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.

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

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

On 10/28/2011 02:41 PM, Eric Firing wrote:
> On 10/28/2011 07:50 AM, 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,
>
> I agree, we have to do this, and now is the time, before the work you
> have already done gets too stale and hard to merge in.
>
> My main worry is how to support the resulting py2.6-py3.2 master:
>
> 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.
Agreed.
>
> 2) This is going to make development significantly harder--having to
> think about the compatibility requirements, and having to test
> everything with 2.x and 3.x.
Yes. What is the status of the buildbots? (I've been really remiss at 
checking them for a very long time now). Having those would be a great 
help.
>
> 3) Most of the interactive backends will be unavailable, correct?
The working ones are Qt4Agg (presumably also Pyside, though untested), 
and Tk. WxPython seems like it's still a long way from supporting 
Python 3 (though I'm not terribly plugged into that community). Note, 
however, the wx backend will continue to work for users running Python 
2.x, just as it always has. There is no need to chop this off 
completely. Gtk is probably ready to be used, I just haven't done the 
testing and twiddling for matplotlib yet.
>
> 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.
Mike

On 10/28/2011 02:41 PM, Eric Firing wrote:
> On 10/28/2011 07:50 AM, 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,
>
> I agree, we have to do this, and now is the time, before the work you
> have already done gets too stale and hard to merge in.
>
> My main worry is how to support the resulting py2.6-py3.2 master:
>
> 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.
Agreed.
>
> 2) This is going to make development significantly harder--having to
> think about the compatibility requirements, and having to test
> everything with 2.x and 3.x.
Yes. What is the status of the buildbots? (I've been really remiss at 
checking them for a very long time now). Having those would be a great 
help.
>
> 3) Most of the interactive backends will be unavailable, correct?
The working ones are Qt4Agg (presumably also Pyside, though untested), 
and Tk. WxPython seems like it's still a long way from supporting 
Python 3 (though I'm not terribly plugged into that community). Gtk is 
probably ready to be used, I just haven't done the testing and twiddling 
for matplotlib yet.
>
> 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.
Mike

On 10/28/2011 07:50 AM, 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,
I agree, we have to do this, and now is the time, before the work you 
have already done gets too stale and hard to merge in.
My main worry is how to support the resulting py2.6-py3.2 master:
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.
2) This is going to make development significantly harder--having to 
think about the compatibility requirements, and having to test 
everything with 2.x and 3.x.
3) Most of the interactive backends will be unavailable, correct?
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.
Eric
>
> 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

On Fri, Oct 28, 2011 at 12:50 PM, Michael Droettboom <md...@st...>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
>
>
I guess it would be fine to start doing that. Are there any recommended
guides for preparing for the transition to py3k. I haven't begun to look
into that and have only been using 2.6 and 2.7 for a while now.
Ben Root

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

On Tue, Oct 25, 2011 at 5:58 PM, Paul Ivanov <piv...@gm...> wrote:
> On Tue, Oct 25, 2011 at 3:52 PM, Daniel Hyams <dh...@gm...> wrote:
>> For small bugfixes, am I supposed to fork from v1.1.x, or master?
>
> I say 'master' (Mike's been pushing some things to v1.1.x, but as he
> said in a comment to #551, "Pushed to v1.1.x since this is pretty
> serious yet simple-to-fix bug -- it should be on the maintenance
> branch.")
Concurring with everything above, with color. It it's a feature, it
should definitely go on master. If it's a serious bug, it should go
on maintenance. If it's a minor bugfix, we can exercise discretion:
if it's simple put it on maintenance; it it's complex, put it on
master.

On Tue, Oct 25, 2011 at 3:52 PM, Daniel Hyams <dh...@gm...> wrote:
> For small bugfixes, am I supposed to fork from v1.1.x, or master?
I say 'master' (Mike's been pushing some things to v1.1.x, but as he
said in a comment to #551, "Pushed to v1.1.x since this is pretty
serious yet simple-to-fix bug -- it should be on the maintenance
branch.")
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7