Indeed, good catch. But another issue comes to my mind: should ax1.title
(that is, "ax1..title.__get__(ax1)" where ".." means no descriptor invoked)
return a string (like now) or something that contains all the properties of
the title? Returning a string copies the current behavior of get_title,
but "ax2.title = ax1.title" would not do what I expect (I would expect
every property related to the title to be copied). Now, if we want
"ax2.title = ax1.title" to work as I expect (what do other people think
here?), then there is no choice but to wrap the return value of __set__.
Antony
2013/2/7 Erik Bray <erik.m.b...@gmail.com>
> On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee <antony....@berkeley.edu>
> wrote:
> > Hi,
> >
> > I saw that a discussion started on transitioning to the use of properties
> > instead of explicit getters and setters, which seems like a very good
> idea
> > to me... so I thought this would be a good idea to get involved in
> > matplotlib-devel :)
> >
> > Right now an issue raised is what to do with set_* that take multiple
> > arguments. Taking set_title, which takes both positional and keyword
> > arguments, as an example, my idea would be to do
> >
> > ax.title = "A title"
> > ax.title.fontdict = fontdict
> >
> > Basically, a property "foo" (in the matplotlib meaning of the word)
> becomes
> > a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword
> > arguments to the old property setter become themselves descriptors on
> that
> > descriptor.
>
> Unfortunately descriptors don't really work like that, because when
> you do `.title` on an instance that doesn't return the descriptor
> itself, it just returns the result of `__get__` on the descriptor. So
> in your example `.fontdict` would have to be an attribute on any
> string assigned as the title. So what you really have to do for this
> to work is to wrap every value returned by the descriptor in some kind
> of proxy that adds the appropriate extra attributes. It also has to
> do so in a way that the proxy can behave transparently like the
> wrapped object, and that none of the wrapped objects attributes are
> overshadowed. And it has to hypothetically work with instances any
> any arbitrary type or class.
>
> While this is somewhat doable for a limited set cases it's really more
> of a can of worms than it's worth. Believe me, I've tried to solve
> similar problems to this one before. A couple easier solutions: Allow
> the `.title` (and other such attributes) to be assigned to with a
> (value, options) tuple where the value is the title itself, and the
> options is a dictionary or tuple of supported options for the title.
> Another solution is to just keep set_title() for cases like this if
> one wishes to set the title with additional options (while still
> allowing `.title = 'foo'` for the simple case).
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
