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

[Todd <tod...@gm...>]

On Fri, Feb 8, 2013 at 10:04 AM, Antony Lee <ant...@be...> wrote:

> 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).
>>
>
> 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
>
>
I think you are trying to make this too smart for its own good.  I think
things should work in a simple, consistent manner.  If the property is set
using a string, then it should return a string.  If you assign a string to
something, it should assign a string only.  If you want to start copying
other properties, we can use a separate property that accepts and returns a
different object, which I am pretty sure was part of my proposal.  This
should be described in the documentation.

So if you want the title fontdict, you get something like
ax1.titletext.fontdict (where titletext is the property for a text object).

Currently ax1.get_title returns a string, so ax2.set_title(ax1.get_title())
will only copy the string.  If we want to change the defaults, so that the
title-related methods work with text objects instead of strings, that is
possible (although would be a major backwards-incompatible API break).  But
that is a separate discussion from MEP13, which only deals with the
transition to properties.  In all cases, under this proposal, I think
properties should be kept as similar as possible to their setters and
getters.  API breaks should be a separate issue.