On Sat, Jul 12, 2008 at 4:31 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> and I am suggesting that this handling of None as a default should > always be moved to a setter if one exists. That way, a user can always > get a property back to its default value by setting it to None. > > Does anyone immediately see any problem or disadvantage in this? (I > have not looked through the code carefully myself, so I could easily be > missing something.) I think localizing the logic into the setters is mostly a win-win proposition, but there are a couple of points you raised that I want to comment on. I consider our overloading of None to mean "do the default, use rc" something of a wart, since it would be more properly handled with a proper object or special value, like a *class RCDefault* instance or a string literal 'rcdefault'. The None handling may be a wart we are committed to because of legacy code, or it may be something we will change, but we should recognize it as a somewhat non-intuitive wart. I say "somewhat" because None is used in other python codes as a default sentinel for mutable keyword arguments (eg, lists and dicts) but otherwise I do not find it terribly obvious. The 2nd comment is that I don't find this use case compelling. Using None in a setter to mean "restore the rc default" may be consistent with the __init__ handling, but it is not something that anyone has ever asked for. In fact, in the use case that prompted this fix, the OP intended 'None' rather than None, so the fact that mpl raised on None rather than reverting to the rc default might be considered a feature rather than a bug. So basically, I'm +0 on this proposal. Better than what we have, not ideal. JDH ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
