[IPython-dev] IPython development news and prospects
ellisonbg.net at gmail.com
Tue Jan 15 14:18:03 EST 2008
> - Traits. As expected, this was likely to be the most problematic
> issue, and I appreciate the feedback from all. It's also something
> that worries *me* a lot, since being pure python, pure stdlib is a
> huge advantage in terms of ease of installation, deployment and use
> for us. I can't count anymore how many times we've gone back and
> forth on this issue, wanting the convenience and elegance of Traits'
> declarative model for data validation and delegation, while worrying
> about the cost of the dependency.
> Brian and I had yesterday what I think was a very useful conversation
> about it, and here's our current proposal on how to address the issue.
> Feedback on this point very much welcome.
> The idea is to write a very lightweight, Traits-like module that does
> only a fraction of what Traits does, but does so with 100% api
> compatibility within that subset. Basically we'd only implement
> - Validation of types (probably only for a very small subset of types
> like strings, numbers and lists)
> - Simple registration of callbacks (listeners), so that changes to
> configuration can trigger the appropriate callbacks to update other
> Since in ipython we're not trying to build something like say Mayavi2,
> but just to organize our config issues cleanly, we'd have to limit
> ourselves to these capabilities, which I don't think is the end of the
> However, we'd put in a global option to enable ipython to use the
> *real* traits if a user wants. This could be used for example by some
> of the higher-level components, for example a Wx-based shell or an
> Envisage (Enthought) plugin could decide to make use of the full power
> of Traits. Obviously for such a project, Traits would then become a
> non-optional dependency, but it's a decision they can each make on a
> case by case basis, rather than being imposed on everyone from the
> very bottom of the project.
> This would mean that there would always be a pure-python ipython that
> operates in a terminal, along with a few optional gui shells that only
> require a given gui toolkit to run. And we may also have traits-using
> tools as well, but those would be optional and "in the leaves" of the
> logical dependency tree, not at the very core.
> How does that sound to everyone? I'm particularly interested in the
> opinion of people like Gael and Robert, who have extensive experience
> working with Traits.
It is also worth mentioning that another factor that led us to this
conclusion is Jython and IronPython. A C dependency would kill any
efforts to get IPython running in those settings.
> IPython-dev mailing list
> IPython-dev at scipy.org
More information about the IPython-dev