> 3. Traits. We (Brian and I) have gone back and forth a lot on Traits, > and we've come very close to just making them a dependency. The only > real issue holding us back is that ipython so far has exactly *zero* > extension code, which is a plus in terms of ease of > installation/deployment. Having said that, as far as extension code > is concerned, Traits is light and clean, and nowhere near the kinds of > complexities that MPL deals with. But since anything is more than > zero, it is a bit of an issue for us. We may tip over though, I'm > just stating what our reasoning so far has been. > > In terms of Traits, point (2) above makes them even more attractive. > The delegation aspect of Traits is a very appealing way of combining > validation with additional action for the runtime modification of an > object. For example: > > ipython.color_scheme = "foo" > > If color_scheme were a Trait, the above could simply: > > a) validate that "foo" was acceptable as a value > b) trigger the chain of other trait updates (dependent color schemes > for exceptions, prompts, etc).
At some level though, configuration is a very different thing than an application's runtime API. While they may be related (by exposing common functionality), not everything that can be configured would appear in a runtime API and vice-versa. Also, some events that need to happen when an attribute is changed at runtime can't happen at config time as the application might not yet be up and running yet. Using Traits in the runtime API is an entirely different ballgame than simply using it for type validation in configuration: When using Traits for validation+configuration, the objects that inherit from HasTraits are simply bunch/dict like objects that do type validation - but they don't contain any application logic. The actually application logic is contained in classes that aren't traited themselves, but that consume traited config objects to configure themselves at startup. If traited objects are exposed in a runtime API, all of a sudden the application logic moves to the traited classes themselves. Then, the entire application (any object that needs config or has a runtime API) is built upon traits at its core. This is very from the previous case where traited classes are used as a minor implementation detail of the config system. I am not saying that it is bad to build an application with traits at its core, but only that that is very different from the path that ipython and matplotlib have taken thus far. Also, it makes the commitment level to traits much higher than if it is used merely as a component in the config system - which could easily be swapped out if desired. Brian > All of this can obviously be done with python properties, but before I > write Traits again, poorly (I'm no David Morrill) I'd rather ride > Enthought's back. > > This approach via Traits (or something like them) also ensures that > the work done in ensuring the consitency/robustness of an object's > *runtime* configuration API becomes automatically useful to users, and > it simplifies the init-time config API, since it gives us the option > to defer more complicated tasks to runtime. > > > So this is a summary of where we stand. It's surprising that the > 'simple question' of configuring an application can turn out to be > such a can of worms, but for us it has proven to be. Input/ideas from > you all would be very welcome, as it's quite likely we've missed > possible solutions. > > I'd love to get out of this discussion some ideas, clarity and > ultimately a plan for how to proceed in the long haul. If in addition > this means that ipython, mpl and others end up uniformizing further > our approach to this problem, even better! Having our end users find > familiar configuration mechanisms across their various libraries would > only be a good thing in the long run. > > Cheers, > > Brian and f. > > > ps - I debated on having this discussion on ipython-dev, but for now > I'm going to not cross-post. The MPL team is attentive to the issue > now, so I'd rather collect your wisdom here, and I'll take it upon > myself to summarize our conclusions on ipython-dev later. I just want > to avoid list cross-posting. > -- Brian E. Granger, Ph.D. Research Scientist Tech-X Corporation phone: 720-974-1850 [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
