John Hunter wrote:
Isn't there a potential problem here? The original validate funcs
support conversion from a string to a value, but you are proposing
using them here in a context where users will generally be supplying a
(possibly bogus) value, but in general not a string. So the existing
funcs may not work wholesale, but might be easily adapted.
What about Fernando's ipython strategy: parse the rc file as python code, not as strings? I don't think the changeover would be very hard; most of the present matplotlibrc file is commented out anyway, so unless users are doing lots of customization it would not be difficult for them to generate a matplotlibrc file in python form.
As for key validation, I was only suggesting you raise a helpful error
message if the user supplies a bogus key.
As for traits, I think we are psychologically committed to them, and
if you are looking for a good summertime project, this might be a good
candidate. It's not really a chainsaw question, because you could
That's why I brought it up--although every time I look at traits I pull back, worrying about the very large amount of machinery they involve. Are any real, live projects outside of enthought making major use of traits? Or would we be the first?
easily support traits in the Artist layer and rc layer w/o ripping out
the fundamental organization, and we could write setter and getter
support as thin warppers around traits to avoid significant API
breakage. There are deeper and more fundamental chainsaw like layers
where traits would help us (eg transform updates on window resizes)
but a clear cut first step would be to get the Artist properties
Actually, it could be completely split into two phases: first rcParams handling, second Artist properties, couldn't it? Starting with rc would be nice because it would provide a gentler introduction and some experience; but I think that using traits for Artist properties can also be done piecemeal, so it shouldn't be too disruptive.
If you decide to go that route, let's sync up with the latest
enthought tree first, though.
I am happy to see this in svn:
Revision 12335, 13.4 kB (checked in by rkern, 4 weeks ago)
Array trait updated to use numpy idioms only.