On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote: > John wrote rc_traits.py, before numpy was around, by the looks of it. Traits > seem more appealing to me than properties, but I was looking for something > that could be done outside of a chainsaw branch. If we decided on traits, we > should also try to do something about the rc file format, so we dont have to > parse and convert strings before validating. Someone had suggested python > literals, I think John or Fernando might have had some ideas about this at > one point... I dont know the details.
Hey Darren, 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. 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 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 traitified. If you decide to go that route, let's sync up with the latest enthought tree first, though. JDH JDH ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
