On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson <pelson....@gmail.com> 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.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to