[IPython-dev] IPython development news and prospects

[Fernando Perez]

Hi all,

first, thanks everyone for the feedback.  I think the enthusiastic
response is a sign that getting this ball rolling was indeed the right
thing to do.  A few things then:

- DVCS (HG). There seems to be broad agreement here, so I'll start
looking into how to actually make it happen.  I'll report back once I
have news of what the final setup will be.

- GUI front ends: we have interest on OSX, Qt4, WX (both the existing
prototype and Laurent's new work).  This is excellent.  A really cool
project once this is in will be a GTK vesion that runs on the OLPC, so
that the real ipython can be the shell of the Pippy programming
activity on the XO.

We'll look into the licensing issues regarding Qt4, and whether we
have to distribute that code as a standalone subproject to avoid GPL
contamination.  So far matplotlib has been shipping its Qt4 support
inside the project without any problems, but if that becomes an issue,
we'll break up the Qt code into a standalone component.  But we *will*
make sure that a Qt4 version can happen as a first-class citizen,
that's promised.

- 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.

Cheers,

f