[matplotlib-devel] mpl_toolkit.axes_grid default axes class should be changed?
Hi,
mpl_toolkit.axes_grid.AxesGrid uses a custom axes type as the default
type of axes it creates. I think it might be more user-friendly to use
matplotlib.axes.Axes as the default -- the functionality in basic use
seems to be the same.
The custom axes handle drawing ticks quite differently from matplotlib's
usual Axes. I just spent an hour wondering why
grid[0].xaxis.get_major_ticks()[-1].label.set_horizontalalignment("right")
had no effect -- the answer is that LocatableAxis draws ticks using a
custom tick artist, and that the correct axis object is in
grid[0].axes["bottom"]. And in fact, it cannot adjust the align of
individual tick labels.
The AxesGrid is really useful, so I'd suggest the following change:
--- lib/mpl_toolkits/axes_grid/axes_grid.py.orig2009-10-27
19:51:43.0 +0200
+++ lib/mpl_toolkits/axes_grid/axes_grid.py 2009-10-27 19:52:13.0
+0200
@@ -210,10 +210,10 @@
if axes_class is None:
-axes_class = LocatableAxes
+axes_class = maxes.Axes
axes_class_args = {}
else:
-if isinstance(axes_class, maxes.Axes):
+if issubclass(axes_class, maxes.Axes):
axes_class_args = {}
else:
axes_class, axes_class_args = axes_class
--
Pauli Virtanen
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl_toolkit.axes_grid default axes class should be changed?
Thanks for your suggestion and the patch.
However, I'm not very inclined to make such a change any time soon,
since that custom axes class is one of my primary motivation
(supporting the cuvelinear grid) behind the axes_grid toolkit. And
other part of axes_grid toolkit depends on this behavior.
On the other hand, I'm trying to make some reorganization effort of
the axes_grid toolkit in the future, during which I will try to
separate out things that depends on the custom axes.
FYI, note that you can turn off the customized behavior by
ax.toggle_axisline(False)
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axisline
This should bring back the original behavior of the matplotlib axes
(if it does not, it should be considered a bug). Of course this will
disable some of the functionality of the axes_grid.
I'm thinking about issuing a warning (about the different behavior
from the original matplotlib) whenever axes_grid is imported
(optinally turned off using rcparams). This may help others not to
wast their time when something does not work.
Regards,
-JJ
On Tue, Oct 27, 2009 at 1:53 PM, Pauli Virtanen wrote:
> Hi,
>
> mpl_toolkit.axes_grid.AxesGrid uses a custom axes type as the default
> type of axes it creates. I think it might be more user-friendly to use
> matplotlib.axes.Axes as the default -- the functionality in basic use
> seems to be the same.
>
> The custom axes handle drawing ticks quite differently from matplotlib's
> usual Axes. I just spent an hour wondering why
>
>
> grid[0].xaxis.get_major_ticks()[-1].label.set_horizontalalignment("right")
>
> had no effect -- the answer is that LocatableAxis draws ticks using a
> custom tick artist, and that the correct axis object is in
> grid[0].axes["bottom"]. And in fact, it cannot adjust the align of
> individual tick labels.
>
> The AxesGrid is really useful, so I'd suggest the following change:
>
> --- lib/mpl_toolkits/axes_grid/axes_grid.py.orig 2009-10-27
> 19:51:43.0 +0200
> +++ lib/mpl_toolkits/axes_grid/axes_grid.py 2009-10-27 19:52:13.0
> +0200
> @@ -210,10 +210,10 @@
>
>
> if axes_class is None:
> - axes_class = LocatableAxes
> + axes_class = maxes.Axes
> axes_class_args = {}
> else:
> - if isinstance(axes_class, maxes.Axes):
> + if issubclass(axes_class, maxes.Axes):
> axes_class_args = {}
> else:
> axes_class, axes_class_args = axes_class
>
> --
> Pauli Virtanen
>
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl_toolkit.axes_grid default axes class should be changed?
Hi! ti, 2009-10-27 kello 15:36 -0400, Jae-Joon Lee kirjoitti: > Thanks for your suggestion and the patch. > However, I'm not very inclined to make such a change any time soon, > since that custom axes class is one of my primary motivation > (supporting the cuvelinear grid) behind the axes_grid toolkit. And > other part of axes_grid toolkit depends on this behavior. > On the other hand, I'm trying to make some reorganization effort of > the axes_grid toolkit in the future, during which I will try to > separate out things that depends on the custom axes. Fair enough. [clip: toggle_axisline] Good to know. Of course, I did not read the fine manual first, which probably explains why I had trouble :). User error, sorry for the noise. > I'm thinking about issuing a warning (about the different behavior > from the original matplotlib) whenever axes_grid is imported > (optinally turned off using rcparams). This may help others not to > waste their time when something does not work. Perhaps it would be enough to explain in the AxisGrid docstring that the default class is a customized one, and that there are implications. Everyone hopefully reads that (at least I did). Thanks, Pauli -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Source tarball should not include setup.cfg (was: 0.99.1.1 build attempts to import non-existing wx)
Erin Sheldon writes: > I just downloaded 0.99.1.1 and I'm finding this error: > wxPython: no > * wxPython not found > Traceback (most recent call last): > File "setup.py", line 146, in > import wx > ImportError: No module named wx This is because the distribution includes a setup.cfg file by mistake. Deleting setup.cfg should allow the autodetection logic to disable building wxagg. This is bug #2871530 on Sourceforge: https://sourceforge.net/tracker/?func=detail&aid=2871530&group_id=80706&atid=560720 I suggest we release a 0.99.1.2, possibly with just this bug fixed, since this problem keeps being reported on the mailing lists. -- Jouni K. Seppänen http://www.iki.fi/jks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
