[IPython-dev] the state if IPython development...

Glenn H Tarbox, PhD glenn at tarbox.org
Tue Mar 18 14:35:38 EDT 2008

I'm having a bit of trouble evaluating various threads of ipython
development and am wondering if I'm missing a comms channel.  I have
various problems which are solveable but don't know which elements of
IPython are going to be refactored away in favor of the IPython1

IPython development has moved, somewhat, to launchpad.  I say somewhat
both from messages on this list and the "bleeding edge" installation

> bzr co --lightweight lp:ipython
> svn co http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline

although a "unified" tarball is downloadable from:

but, I had trouble with the pyreadline build directly from svn:

copying pyreadline/modes/__init__.py -> build/lib/pyreadline/modes
copying pyreadline/modes/notemacs.py -> build/lib/pyreadline/modes
package init file 'pyreadline/test/__init__.py' not found (or not a
regular file)

I didn't drill down completely but this looks like something inside the
package.  So, I guess I don't know whether pyreadline within the IPython
svn pull is ok, whether one needs to pull both, is there something
strange going on when one already has ipython installed?... and don't
know whether I should spend any time on this because I can't tell whats

More concerning is the state of Qt4.  There is a "critical" bug entered
in trac: http://projects.scipy.org/ipython/ipython/ticket/208

Clearly, a QCoreApplication (or QApplication) instance is
auto-constructed due to the -q4thread switch... and since calculate.py
constructs one also, QT dumps core  (why QT decides to core-dump as the
error reporting strategy is beyond me... but thats whats going on).

Qt4 support is indeed broken... but unnecessarily so. I have Qt4 running
with twisted in a naked ipython shell.  I simply construct my qt4reactor
and use embedded Qt4 code.  Can't pull in pylab because it renames
packages which collide with PyQt4 (in particular, wrapping QObject in a
different module... don't get that yet).  and this is beyond the issues
associated with QSocketNotifier being invoked from a non-qt thread.  I'm
sure this is straightforward but, again, I can't determine whether time
spent here is worthwhile.  Seems to me that IPython1's architecture will
make most of these problems "just go away" as its a far more
comprehensive architecture.

(BTW: the twisted qt reactor can be retrieved from
http://noc2.tarbox.org:8080/?p=qtreactor/.git;a=summary )

On a related point, I think we're headed for trouble with wx.  I notice
that its included in IPython1... but the twisted wxreactor is a bit
broken.  I think its easy to fix, but the reason its broken is because
wx was poorly behaved when the wxreactor was developed (stopped
servicing timers, IO notification during modal windows etc) and the
twisted folks used threading to get around the difficulty.  Nothing
wrong with that, other than its ugly (and will cause other threadosity
issues) but the code doesn't work properly (fails tests, I support the
buildbot) and I wonder whether its worth fixing or whether its easier to
get wx to behave (I can drill down into the issues here with anyone who
wants but I won't digress further here).

Also, I note that there's virtually no traffic on freenode, at least not
on #scipy (am I missing a channel?)  Seems to me that the IPython1
development activity would be greatly served by greater irc activity.

Finally, I support 4 buildbots for twisted.  I'm willing to provide
these same assets for IPython1 development (each server has dual - 4
core processors = 8 processors / server totaling 32 processors).  How to
properly use this setup for cluster testing would need to be discussed.


Glenn H. Tarbox, PhD
glenn at tarbox.org

More information about the IPython-dev mailing list