On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote: >> = Z-ordering, containers, etc = >> >> Peter has been doing a lot of nice work on z-order and layers for >> chaco, stuff that looks really useful for picking, interaction, >> etc... >> We should look at this approach, and think carefully about how this >> should be handled. > > Is there somewhere in particular that I can look to see what > Peter's been working on? Enthought's svn repositories?
I would recommend grabbing the eggs: https://svn.enthought.com/enthought/wiki/InstallWithEggs After installing the eggs, you can grab the chaco2 examples from SVN: svn co https://svn.enthought.com/svn/enthought/branches/ enthought.chaco2_2.0/examples Let me know if you have any problems! >> = Traits = >> I think we should make a major committment to traits and use them >> from >> the ground up. Even without the UI stuff, they add plenty to make >> them worthwhile, especially the validation and notification features. > > I hate to be the first one to disagree, but here goes: traits give > me the heebie-jeebies. I agree that matplotlib 1.0/2.0 needs to > validate all user-settable parameters. However, I'm concerned > about the development overhead that might result from making traits > as a core dependency. Code readability is also a concern to me -- > the experience of reading mpl1.py suggests to me that newcomers > might find traits a bit too "voodoo". I'm confident that the same > thing could be achieved using Python properties to validate > attributes. This is a true statement. In fact, the first version of traits basically used properties to implement a lot of the validation and notification. Eventually for power and speed, we moved to using a metaclass with a C extension. I think the code readability question comes down to "is it easier for someone to learn some basic things about traits, or is it easier for them to decipher the massive jumble of property setters and getters I've wired up"? I think that the amount of duplicated code that has to written using simple python properties is non-trivial. Of course, this being Python, people are going to be tempted to write some code to generate code or at least do some simple metaprogramming when they are faced with writing their 50th setter/getter. This then leads to the problem of documenting and testing the code-generating functions, and newcomers will have to learn about those and what they mean and what their side effects are. With traits, there is at least a well- tested and documented design that has been through the ringer a few times. > Change notification is another matter, granted, but I think that a > major rewrite will provide the opportunity to better design for > those situations. I actually think that change notification, more so than validation, is the killer feature of traits. After you write enough code with objects that communicate via notifications, you start really thinking of your running program as a little ecosystem of live objects, and it's an entirely different mental model for design and implementation. It's especially reinforced if you use Traits UI to bring up dialogs to interact with these live objects, or use IPython to start twiddling them as they're running, and you can see things change realtime, automagically. Just my (slight biased) $.02. :) -Peter ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
