[IPython-user] [IPython-dev] IPython development news and prospects

Brian Granger ellisonbg.net@gmail....
Tue Jan 15 13:18:03 CST 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
> things.
>
> 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
> world.
>
> 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.


> Cheers,
>
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


More information about the IPython-user mailing list