On Thu, Jan 17, 2013 at 11:30 AM, Todd <tod...@gm...> wrote: > On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson <pel...@gm...> wrote: > >> Hi Todd, >> >> I agree with the principle of properties - it will make much of the mpl >> codebase (and user code) more pythonic, so thanks for proposing this. >> >> Would you be able to give an example of how you propose setters such as >> Axes.set_xlim might make use of properties. The particular example I >> have picked uses keywords to determine the behaviours of the method itself: >> >> def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw): >> ... >> >> >> For me, the backwards compatibility issue is the key blocker to this MEP. >> Would you mind providing some concrete examples (perhaps using the set_xlim >> method as a focus point)? >> >> Cheers, >> >> Phil >> >> > Methods like that will be a problem. I see two possible approaches (which > are not mutually exclusive): > > 1. keep the set_xlim method for more sophisticated cases. > 2. split the set_xlim method into several methods > > Frankly I am not sure deprecating the existing setter and getter methods > is really called for. It may not be worth the trouble for users. That is > why I said everything in the MEP is very tentative. > > For approach 1, we would keep the current method, but also have another > method: > > @xlim.setter > def xlim(self, lims): > ... > > so for the basic case, just setting the lims, you would do: > > axesobj.xlims = (leftval, rightval) > > For approach 2, you would have additionally have (there is already an > autoscale_x_on method): > > @autoscale_x.setter > def autoscale_x(self, auto): > ... > > > @emit_xlim.setter > def emit_xlim(self, emit): > ... > > > @xlim_left.setter > def xlim_left(self, left): > ... > > > @xlim_right.setter > def xlim_right(self, rigth): > ... > > (or you could do some python-fu to allow you to assign values to the > xlim[0] and xlim[1]) > > This would require setting three separate attributes. However, we would > already have the autoscale_x property. > > In my opinion breaking up the API into separate calls would be a cleaner > approach anyway. Setters and getters should be setters and getters, they > shouldn't be modifying other unrelated values. But that does not mean we > have to remove the existing approach. > > > > I've added examples of two examples of difficult cases to the MEP. I've also added more specific details of how to deal with them. The MEP is still written under the assumption that we will ultimately deprecate the existing setter and getter methods but, as I said, whether this is the best approach is highly questionable.