Erik Tollerud wrote: > Personally, I think traits must be kept out of MPL, for three main reasons: > As these comments are in respose to my email, let me again state the main point of my email:
My main feeling about MPL is that there's just too much layout happening to keep using the non-systematic delegation/notification "system" currently in place while allowing the devs to maintain their sanity and day jobs. [...] Therefore, I'd suggest that before adding on too many more nice features, we revisit the core layout and delegation system -- in the end it will make everything much easier. So, perhaps a useful thing would be for as many MPL devs as possible to sit together and discuss how we could do this. Thus, I was suggesting traits as a means to an end (a saner core), and not something for its own sake. > 1. As Eric Bruning points out, while traits is a very powerful tool, > it also closes a lot of doors by forcing everything to be written in a > trait-like fashion for it to play nice with everything else. While > this is great for many applications, I think it does not necessarily > belong everywhere, particularly given a tendancy to quickly snowball > in complexity (not to mention any new people that want to contribute > code have an extra thick manual to read). > I wasn't proposing to touch the user API for MPL. I think we'd be silly to do that. > 2. Installation of traits or traitsgui should not be a necessity for > MPL... perhaps this will change in the future, but it's currently a > far bigger task to get traits and traits UI working on an arbitrary > system than it is to get MPL up and running (at least, that's been my > experience in a number of different settings). > Well, I don't think we need traits UI, and I don't imagine traits itself is hard to build, although I could be wrong (I always use the Ubuntu/Debian packages). > 3. Chaco - my general mindset on this is that Chaco is great for > plotting any and everything in a traits gui, but MPL is much better > for the quickcalculations and plots that I make every day as a > scientist. When a critical mass is reached it becomes better to > integrate a tool into a GUI app, MPL becomes more difficult to manage > and chaco is a better tool. But I think it makes a lot of sense to > leverage MPL most as the wonderful "quick-and-dirty" command-line > interactive plotting environment that it is rather than making it > application-centric, which is where I can envision it going as soon as > it has to run with traits. > > Now a great idea would be to include optional support for things like > setting configuration files from a traits interface - I know I've seen > talk of doing this for matplotlibrc at some point, and I'd definitely > use that. Simlarly, some sort of traits-level extension to support > more interactive plots and better layout seems like it could be done > without requiring the core to use traits. > OK, but these don't address my main concern that the core layout of MPL is an unwieldy beast. Anyhow, as I'm way too busy to think about any real coding on MPL's core right now, this is just cheap talk... -Andrew ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
