matplotlib-devel Mailing List for matplotlib

All,
Based on what everyone has been saying I have submitted an update to axes.py that reverts the get/set xlim/ylim methods to their
original state with their original interface. I have removed the state flag that keeps track of inverted axes.
Currently I have added the method get/set xbound/ybound that handles getting and setting of the upper and lower bounds and will
handle inverted axes. I have made a couple of changes within the Axes class to now call the xbound/ybound methods so that the
handling of inversion is automatic. This at least solves the immediate problems and provides some level of protection by giving a
"safe" method to call when writing methods that deal with axes limits.
Let me know what you think.
--James Evans
> -----Original Message-----
> From: Ted Drain [mailto:ted...@jp...]
> Sent: Thursday, October 04, 2007 2:34 PM
> To: Eric Firing
> Cc: James Evans; John Hunter; matplotlib development list
> Subject: Re: [matplotlib-devel] API additions
> 
> Sounds fine - I don't think we care too much about the "how". I
> talked w/ James and as far as we know, the aspect code is the only
> area that's having a problem right now (James is going to submit a
> patch to that to handle x1>x2 today).
> 
> Since we do these plots all the time, we've just seen a number of
> problems come up as new features get added and people forget that
> x1 > x2 is a possibility. We were just trying to think of ways of
> "future proofing" the new system by making it more obvious that this
> case does show up. It might be able to be handled by some extra
> comments in the existing code so that people who are looking for
> examples would get a reminder that this case has to be handled.
> 
> Ted
> 
> At 02:11 PM 10/4/2007, Eric Firing wrote:
> >Ted Drain wrote:
> > > John,
> > > I think keeping the existing API is probably a good idea. What about
> > > something like this:
> > >
> > > - Keep xlim and viewlim as they are.
> > >
> > > - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> > >
> > > - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and
> > > then calls set_xlim() w/ the args in the proper order.
> >
> >The fundamental object containing the relevant information is the
> >Interval instance. Instead of having a proliferation of flags and
> >functions at the python level, I am thinking about adding a few very
> >simple methods to the Interval object. Maybe
> >
> >swap() to reverse the order of the bounds
> >increasing() to yield True if val2 >= val1
> >
> >Your xbound and set_xbound functionality could also be done this way, as
> >Interval methods.
> >
> >
> >Mike, how would this fit in with your reworking of transforms?
> >
> >Eric
> >
> > >
> > > - Change the existing axis code that messes w/ bounds (autoscale, aspect
> > > ratio, etc) to use xbound. These algorithm can then be written so
> > > they're independent of the order of x1 and x2 and they won't flip the
> > > bounds back if the inversion flag is set.
> > >
> > > Ted
> >
> >-------------------------------------------------------------------------
> >This SF.net email is sponsored by: Splunk Inc.
> >Still grepping through log files to find problems? Stop.
> >Now Search log events and configuration files using AJAX and a browser.
> >Download your FREE copy of Splunk now >> http://get.splunk.com/
> >_______________________________________________
> >Matplotlib-devel mailing list
> >Mat...@li...
> >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> Ted Drain Jet Propulsion Laboratory ted...@jp...
> 

Sounds fine - I don't think we care too much about the "how". I 
talked w/ James and as far as we know, the aspect code is the only 
area that's having a problem right now (James is going to submit a 
patch to that to handle x1>x2 today).
Since we do these plots all the time, we've just seen a number of 
problems come up as new features get added and people forget that 
x1 > x2 is a possibility. We were just trying to think of ways of 
"future proofing" the new system by making it more obvious that this 
case does show up. It might be able to be handled by some extra 
comments in the existing code so that people who are looking for 
examples would get a reminder that this case has to be handled.
Ted
At 02:11 PM 10/4/2007, Eric Firing wrote:
>Ted Drain wrote:
> > John,
> > I think keeping the existing API is probably a good idea. What about
> > something like this:
> >
> > - Keep xlim and viewlim as they are.
> >
> > - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> >
> > - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and
> > then calls set_xlim() w/ the args in the proper order.
>
>The fundamental object containing the relevant information is the
>Interval instance. Instead of having a proliferation of flags and
>functions at the python level, I am thinking about adding a few very
>simple methods to the Interval object. Maybe
>
>swap() to reverse the order of the bounds
>increasing() to yield True if val2 >= val1
>
>Your xbound and set_xbound functionality could also be done this way, as
>Interval methods.
>
>
>Mike, how would this fit in with your reworking of transforms?
>
>Eric
>
> >
> > - Change the existing axis code that messes w/ bounds (autoscale, aspect
> > ratio, etc) to use xbound. These algorithm can then be written so
> > they're independent of the order of x1 and x2 and they won't flip the
> > bounds back if the inversion flag is set.
> >
> > Ted
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about 
> something like this:
> 
> - Keep xlim and viewlim as they are.
> 
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> 
> - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and 
> then calls set_xlim() w/ the args in the proper order.
The fundamental object containing the relevant information is the 
Interval instance. Instead of having a proliferation of flags and 
functions at the python level, I am thinking about adding a few very 
simple methods to the Interval object. Maybe
swap() to reverse the order of the bounds
increasing() to yield True if val2 >= val1
Your xbound and set_xbound functionality could also be done this way, as 
Interval methods.
Mike, how would this fit in with your reworking of transforms?
Eric
> 
> - Change the existing axis code that messes w/ bounds (autoscale, aspect 
> ratio, etc) to use xbound. These algorithm can then be written so 
> they're independent of the order of x1 and x2 and they won't flip the 
> bounds back if the inversion flag is set.
> 
> Ted

Ted Drain wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping it. 
> Calling set_xlim() to invert is fine - but it never seems to stay that 
> way. There is a lot of code (resizing, autoscaling, labelling, etc) 
> that has a tendency to flip the axis back to it's 'un-inverted' state. 
> The idea behind having a flag on the axis itself is so that other code 
> can check that easily to see what the state of the axis is.
> 
> We do a lot of plots that require an inverted axis and we've had tons of 
> problems keeping the axis inverted (which is where the idea for the flag 
> came from). It seems like people forget that this is possible and add 
> code that assumes that xmin < xmax which then ends up flipping the axis 
> back to it's "normal" state (this happens in the aspect ratio code for 
> example).
OK, I found an example with set_aspect(2, adjustable='datalim').
I would still like to see as many specific examples as you can provide.
Eric
> 
> Ted

Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about 
> something like this:
> 
> - Keep xlim and viewlim as they are.
> 
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
> 
> - Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, and 
> then calls set_xlim() w/ the args in the proper order.
> 
> - Change the existing axis code that messes w/ bounds (autoscale, aspect 
> ratio, etc) to use xbound. These algorithm can then be written so 
> they're independent of the order of x1 and x2 and they won't flip the 
> bounds back if the inversion flag is set.
I'm not sure whether additional flags and functions are even needed to 
clean up the problems, but they might make it easier. I can take a look 
at this over the weekend. The problems may well be in code I wrote 
(like aspect ratio handling). I would be inclined to try to clean up the 
naming--if what is really meant in the code is "left", not "xmin", then 
that is what it should be called. I don't think fixing that will be too 
big a deal.
Ted, if you can supply some simple examples that illustrate the bugs, 
that would be most helpful. (Apologies if you have already done so and I 
missed it.)
Changing the API is still on the table, but I would rather see first 
whether we can come up with a clean solution using the existing API.
Eric
> 
> Ted
> 
> 
> At 08:05 AM 10/4/2007, John Hunter wrote:
>> On 10/4/07, Ted Drain <ted...@jp...> wrote:
>> > John,
>> > I think that the problem isn't doing the inversion - it's keeping
>> > it. Calling set_xlim() to invert is fine - but it never seems to
>> > stay that way. There is a lot of code (resizing, autoscaling,
>> > labelling, etc) that has a tendency to flip the axis back to it's
>> > 'un-inverted' state. The idea behind having a flag on the axis
>> > itself is so that other code can check that easily to see what the
>> > state of the axis is.
>> >
>>
>> > We do a lot of plots that require an inverted axis and we've had tons
>> > of problems keeping the axis inverted (which is where the idea for
>> > the flag came from). It seems like people forget that this is
>> > possible and add code that assumes that xmin < xmax which then ends
>> > up flipping the axis back to it's "normal" state (this happens in the
>> > aspect ratio code for example).
>>
>> I see -- I missed James' original email describing the motivation for
>> this flag because it was in spam quarantine (I think he posted from a
>> non-subscribed address). As I was just clearing out the spam, I
>> noticed it, and now better understand what you are trying to do. It
>> seems like a reasonable use case.
>>
>> If I am reading this right, there is no way to support this kind of
>> behavior *and* not break existing code. If we want to go this route,
>> I don't mind breaking existing code as long as we do it cleanly. Eg,
>> I think xmin and xmax should always be in order (calls to
>> set_xlim(xmax, xmin) would raise a helpful exception like "call
>> ax.invert_xaxis instead") and we would need to make sure that the
>> viewlim are still reversed per Michael's request. And we would need a
>> clean way to toggle back. In this view:
>>
>> ax.xaxis_invert() # turns inversion on and off
>> ax.get_xlim() # always returns xmin, xmax
>> ax.set_xlim(blah) # requires xmin<xmax
>>
>> and viewlim behave as before.
>>
>> This would also satisfy Eric's point that xmin and xmax are poorly named.
>>
>> The one thing I find potentially confusing about Jame's original post
>> is that set_xlim can be out of order (xmin>xmax) while get_xlim always
>> returns ordered values.
>>
>> For the record, I almost never use inverted axes so we should hear
>> more from those who do....
>>
>> JDH
> 
> Ted Drain Jet Propulsion Laboratory ted...@jp... 
> 

John,
I think keeping the existing API is probably a good idea. What about 
something like this:
- Keep xlim and viewlim as they are.
- Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
- Add set_xbound(x1,x2) that takes x1<x2, checks the inversion flag, 
and then calls set_xlim() w/ the args in the proper order.
- Change the existing axis code that messes w/ bounds (autoscale, 
aspect ratio, etc) to use xbound. These algorithm can then be 
written so they're independent of the order of x1 and x2 and they 
won't flip the bounds back if the inversion flag is set.
Ted
At 08:05 AM 10/4/2007, John Hunter wrote:
>On 10/4/07, Ted Drain <ted...@jp...> wrote:
> > John,
> > I think that the problem isn't doing the inversion - it's keeping
> > it. Calling set_xlim() to invert is fine - but it never seems to
> > stay that way. There is a lot of code (resizing, autoscaling,
> > labelling, etc) that has a tendency to flip the axis back to it's
> > 'un-inverted' state. The idea behind having a flag on the axis
> > itself is so that other code can check that easily to see what the
> > state of the axis is.
> >
>
> > We do a lot of plots that require an inverted axis and we've had tons
> > of problems keeping the axis inverted (which is where the idea for
> > the flag came from). It seems like people forget that this is
> > possible and add code that assumes that xmin < xmax which then ends
> > up flipping the axis back to it's "normal" state (this happens in the
> > aspect ratio code for example).
>
>I see -- I missed James' original email describing the motivation for
>this flag because it was in spam quarantine (I think he posted from a
>non-subscribed address). As I was just clearing out the spam, I
>noticed it, and now better understand what you are trying to do. It
>seems like a reasonable use case.
>
>If I am reading this right, there is no way to support this kind of
>behavior *and* not break existing code. If we want to go this route,
>I don't mind breaking existing code as long as we do it cleanly. Eg,
>I think xmin and xmax should always be in order (calls to
>set_xlim(xmax, xmin) would raise a helpful exception like "call
>ax.invert_xaxis instead") and we would need to make sure that the
>viewlim are still reversed per Michael's request. And we would need a
>clean way to toggle back. In this view:
>
> ax.xaxis_invert() # turns inversion on and off
> ax.get_xlim() # always returns xmin, xmax
> ax.set_xlim(blah) # requires xmin<xmax
>
>and viewlim behave as before.
>
>This would also satisfy Eric's point that xmin and xmax are poorly named.
>
>The one thing I find potentially confusing about Jame's original post
>is that set_xlim can be out of order (xmin>xmax) while get_xlim always
>returns ordered values.
>
>For the record, I almost never use inverted axes so we should hear
>more from those who do....
>
>JDH
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On 10/4/07, Ted Drain <ted...@jp...> wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping
> it. Calling set_xlim() to invert is fine - but it never seems to
> stay that way. There is a lot of code (resizing, autoscaling,
> labelling, etc) that has a tendency to flip the axis back to it's
> 'un-inverted' state. The idea behind having a flag on the axis
> itself is so that other code can check that easily to see what the
> state of the axis is.
>
> We do a lot of plots that require an inverted axis and we've had tons
> of problems keeping the axis inverted (which is where the idea for
> the flag came from). It seems like people forget that this is
> possible and add code that assumes that xmin < xmax which then ends
> up flipping the axis back to it's "normal" state (this happens in the
> aspect ratio code for example).
I see -- I missed James' original email describing the motivation for
this flag because it was in spam quarantine (I think he posted from a
non-subscribed address). As I was just clearing out the spam, I
noticed it, and now better understand what you are trying to do. It
seems like a reasonable use case.
If I am reading this right, there is no way to support this kind of
behavior *and* not break existing code. If we want to go this route,
I don't mind breaking existing code as long as we do it cleanly. Eg,
I think xmin and xmax should always be in order (calls to
set_xlim(xmax, xmin) would raise a helpful exception like "call
ax.invert_xaxis instead") and we would need to make sure that the
viewlim are still reversed per Michael's request. And we would need a
clean way to toggle back. In this view:
 ax.xaxis_invert() # turns inversion on and off
 ax.get_xlim() # always returns xmin, xmax
 ax.set_xlim(blah) # requires xmin<xmax
and viewlim behave as before.
This would also satisfy Eric's point that xmin and xmax are poorly named.
The one thing I find potentially confusing about Jame's original post
is that set_xlim can be out of order (xmin>xmax) while get_xlim always
returns ordered values.
For the record, I almost never use inverted axes so we should hear
more from those who do....
JDH

John,
I think that the problem isn't doing the inversion - it's keeping 
it. Calling set_xlim() to invert is fine - but it never seems to 
stay that way. There is a lot of code (resizing, autoscaling, 
labelling, etc) that has a tendency to flip the axis back to it's 
'un-inverted' state. The idea behind having a flag on the axis 
itself is so that other code can check that easily to see what the 
state of the axis is.
We do a lot of plots that require an inverted axis and we've had tons 
of problems keeping the axis inverted (which is where the idea for 
the flag came from). It seems like people forget that this is 
possible and add code that assumes that xmin < xmax which then ends 
up flipping the axis back to it's "normal" state (this happens in the 
aspect ratio code for example).
Ted
At 07:28 AM 10/4/2007, John Hunter wrote:
>On 10/4/07, Michael Droettboom <md...@st...> wrote:
>
> > def invert_xaxis(self, invert=True):
> >
> > "Invert the x-axis if 'invert' is True."
> >
>
>I like this approach over a state flag (I agree with Eric that it
>would be nice to avoid if we can since it complicates communication
>between different parts of the Axes and Axis code). But why do we
>need an invert kwarg. I would imagine that invert_xaxis might work
>like
>
>def invert_xaxis(self):
> left, right = self.get_xlim()
> self.set_xlim(right, left)
>
>then you could toggle back and forth
>
>and xaxis_inverted would work as you propose.
>
>JDH
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On 10/4/07, Michael Droettboom <md...@st...> wrote:
> def invert_xaxis(self, invert=True):
>
> "Invert the x-axis if 'invert' is True."
>
I like this approach over a state flag (I agree with Eric that it
would be nice to avoid if we can since it complicates communication
between different parts of the Axes and Axis code). But why do we
need an invert kwarg. I would imagine that invert_xaxis might work
like
def invert_xaxis(self):
 left, right = self.get_xlim()
 self.set_xlim(right, left)
then you could toggle back and forth
and xaxis_inverted would work as you propose.
JDH

On Tue, Oct 02, 2007 at 10:42:13AM -0400, Paul Kienzle wrote:
> As I was building a py2exe distribution of matplotlib, I noticed the
> function get_py2exe_datafiles() in __init__.py that is not noted on
> the FAQ. Before I update the FAQ, can you all tell me your best
> practices recommendations for wrapping matplotlib?
> 
> In particular, is there a way I can store the matplotlib data directly
> in the exe so that install is simply a matter of copying an exe file
> rather than a whole directory?
> 
> Technically this should be feasible --- freetype can load fonts
> from memory or directly from the zip file given the proper driver,
> and the various images should be similarly readable.
For the record, here is what I'm using to wrap matplotlib in py2exe.
Since I'm using the wx backend I've excluded Tkinter. 
Since numerix uses __import__, py2exe wasn't clever enough to find the 
numerix extensions, and had to be listed explicitly. Similarly 
for backends.
I'm not picking up the 14Mb of timezone info that I don't need. Maybe
want packages = ['pytz'] if your applications need it.
I haven't addressed mpl-data yet.
	- Paul
myapp.py
========
import pylab
pylab.plot(range(10),range(10))
pylab.show()
setup.py
========
from distutils.core import setup
import sys, os, py2exe
# data_files: List of datafiles that need to be explicitly included
# e.g., [('target/relative/path', ['file','list'])]
# excludes: List of modules to exclude (takes precedence over includes)
# dll_excludes: List of dlls to exclude
# includes: List of modules to include
# packages: List of packages to include
data_files = []
excludes = [ 'numarray', 'Numeric', 'Tkinter', ]
dll_excludes = [] # dlls to exclude
includes = [ 'matplotlib', 'wx', 'numpy', ]
packages = [] # May want 'wx' in packages if creating a generic environment
# Explicit package rules
if 'matplotlib' in includes:
 import matplotlib
 data_files += matplotlib.get_py2exe_datafiles()
 includes += ['matplotlib.numerix.'+pkg for pkg in
 ['ma','mlab','fft','linear_algebra','npyma','random_array']]
 includes += ['matplotlib.backends.backend_'+pkg for pkg in
 ['wx','wxagg','pdf','ps','svg','agg','agg2','emf']]
# Don't include anything explicitly excluded
includes = [x for x in includes if x not in excludes]
# Include the C/C++ runtime (there should be a way of putting these beside
# the python dll in the executable, but for now I put them in the executable
# directory. Note: the C++ runtime might be in the wx package instead of the
# python directory.
pythonpath = os.path.dirname(sys.executable)
c_runtime = pythonpath+"/MSVCR71.DLL"
cpp_runtime = pythonpath+"/MSVCP71.DLL"
data_files += [('.',[c_runtime,cpp_runtime])]
# End of configuration
py2exe_opts = dict(includes=includes, excludes=excludes,
 skip_archive=0, compressed=1,
 dll_excludes=dll_excludes, packages=packages,
 bundle_files=1, optimize=2)
setup(
 options = dict(py2exe=py2exe_opts),
 windows= ['myapp.py'], # Could be console=, depending on your app
 data_files = data_files,
 #zipfile = None, # Bundle library.zip with the executable
 )

James,
In principle, I'm not against adding a new API for this as long as the 
old one doesn't break.
I just have the usual concerns that callers of get_xlim/get_ylim don't 
break because of this. The things I've tried so far seem to be working, 
but all calls to get_xlim/get_ylim should be tested exhaustively, to 
make sure that none of them depend on xmin > xmax when the axis is inverted.
 From the point of view of the transforms refactoring megabranch I'm 
working on, my only concern is that viewLim stays as-is -- that is, if 
the axis is inverted, then the values in viewLim are also inverted. 
That appears to be how you've kept things in your change -- I'd just 
like to put in my vote for that remaining the case regardless of where 
this discussion about API goes.
There does seem to be one small logic bug in the change. If I invert 
the axis (in the old way), I can't then uninvert it in the old way:
axes().set_xlim(0.5, -0.5)
axes().set_xlim(-0.5, 0.5)
# The x-axis is still inverted
I think we have to keep this API working as-is (as it's a pretty common 
one), even if we extend it with invert_xaxis. One possible solution may 
be to not change set_xlim at all, and make get_xlim, invert_xaxis, and 
xaxis_inverted more dynamic, i.e. don't use a _invertedx flag [untested 
code warning]:
 def get_xlim(self):
	xmin, xmax = self.viewLim.intervalx().get_bounds()
	if xmax < xmin:
		return xmax, xmin
	return xmin, xmax	
 def invert_xaxis(self, invert=True): 
 "Invert the x-axis if 'invert' is True." 
	xmin, xmax = self.viewLim.intervalx().get_bounds()
	if invert:
	 if xmin < xmax:
		self.viewLim.intervalx().set_bounds(xmax, xmin) 			else:
 	 if xmax < xmin:
		self.viewLim.intervalx().set_bounds(xmax, xmin)
 def xaxis_inverted(self): 
 'Returns True if the x-axis is inverted.' 
	xmin, xmax = self.viewLim.intervalx()
	return xmax < xmin	
One very minor point: the function name "invert_xaxis", to me suggests 
that the direction of the axis will "toggle" and that two calls to 
invert_xaxis would restore it to the original state. However, I think 
the function as you designed it is more useful -- perhaps it just needs 
a different name.
I agree with Eric's comment:
 > I also thought the old scheme of xlim(5,0) was elegant; the problem was
 > that there and in related functions the variables should have been
 > called "left" and "right", not "xmin" and "xmax".
But getting out of that situation may be more trouble than it's worth...
Cheers,
Mike
Eric Firing wrote:
> James,
> 
> I see that you have implemented a strategy change in axes.py for 
> inverted axes, with corresponding additions to the API. I don't have 
> strong opinions about the strategy. Keeping track of orientation via a 
> flag is reasonable, although I'm not positive it is better, given that 
> it complicates the API. My first reaction to the new API is at best 
> lukewarm, however, so perhaps it is worth a bit of thrashing out on the 
> list.
> 
> What you have now (and similarly for yaxis):
> 
> + def invert_xaxis(self, invert=True):
> + "Invert the x-axis if 'invert' is True."
> + self._invertedx = invert
> +
> + def xaxis_inverted(self):
> + 'Returns True if the x-axis is inverted.'
> + return self._invertedx
> 
> 
> Some alternatives:
> 
> 1) Attributes (could later be properties or those terrifying traits):
> x_right=True or False
> y_up
> 
> xdir 'right' or 'normal' or True; vs 'left' or 'reversed' or False
> and similarly for ydir
> 
> 2) Getters and setters:
> set_xdir() with values as some selection from above
> ydir() similar
> set_xRight(False)
> yUp(False)
> 
> Matlab uses "xdir", "reversed" etc.
> 
> I like the idea of being more descriptive, with "right"|"left" and 
> "up"|"down", either as values or in the function and/or attribute names.
> 
> I also thought the old scheme of xlim(5,0) was elegant; the problem was 
> that there and in related functions the variables should have been 
> called "left" and "right", not "xmin" and "xmax".
> 
> I could probably come up with more possibilities, but first I want to 
> see whether anyone agrees that this might be a good time to think about 
> API strategy and consistency.
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

James,
I see that you have implemented a strategy change in axes.py for 
inverted axes, with corresponding additions to the API. I don't have 
strong opinions about the strategy. Keeping track of orientation via a 
flag is reasonable, although I'm not positive it is better, given that 
it complicates the API. My first reaction to the new API is at best 
lukewarm, however, so perhaps it is worth a bit of thrashing out on the 
list.
What you have now (and similarly for yaxis):
+ def invert_xaxis(self, invert=True):
+ "Invert the x-axis if 'invert' is True."
+ self._invertedx = invert
+
+ def xaxis_inverted(self):
+ 'Returns True if the x-axis is inverted.'
+ return self._invertedx
Some alternatives:
1) Attributes (could later be properties or those terrifying traits):
 x_right=True or False
 y_up
 xdir 'right' or 'normal' or True; vs 'left' or 'reversed' or False
and similarly for ydir
2) Getters and setters:
 set_xdir() with values as some selection from above
 ydir() similar
 set_xRight(False)
 yUp(False)
Matlab uses "xdir", "reversed" etc.
I like the idea of being more descriptive, with "right"|"left" and 
"up"|"down", either as values or in the function and/or attribute names.
I also thought the old scheme of xlim(5,0) was elegant; the problem was 
that there and in related functions the variables should have been 
called "left" and "right", not "xmin" and "xmax".
I could probably come up with more possibilities, but first I want to 
see whether anyone agrees that this might be a good time to think about 
API strategy and consistency.
Eric