Re: [matplotlib-devel] my $0.02 on MEP13

[Antony L. <ant...@be...>]

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 <eri...@gm...>

> On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee <ant...@be...>
> 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).
>