[IPython-user] [Python-Dev] a quit that actually quits

Fernando Perez Fernando.Perez at colorado.edu
Fri Dec 30 01:33:01 CST 2005

[ switching to my normal address, else I'll miss your messages.  I'm also 
cc-ing the ipython list for this discussion: I prefer to keep such matters 
there, for archival/search purposes, for the benefit of others, and for my own 
organizational sanity ]

Walter Dörwald wrote:
> Fernando Perez wrote:

>> And you're on your way to re-writing ipython:
> I *am* on my way to rewriting ipython actually! ;)

It's a long road :)

>> I also started it with "let's add a cool hack to sys.ps1 and
>> sys.displayhook in 10 minutes".  Now we're at 18000 lines of python, a 70
>> page manual, and growing suport for remote distributed interactive
>> computing, a new scientific computing GUI, and more  :)
> That's what scares me. I've been using a simple displayhook and excepthook
> for years now. Later I've tried out ipython and liked some of it's
> features, but it was to much bl%ck m%gic for my taste and I found ipython
> hard to extend, so I went back to using my own stuff and began writing my
> own shell based on code.InteractiveConsole. (It's currently at about 300
> lines of code)

IPython is easy to extend, it's just hard to know where to start :)  The 
problem is that the current code grew 'organically' (to put it nicely), and 
the internals are a hideous spaghetti mess.  There are extension points for 
many things, but you'd mostly have to ask me on the list for details on how to 
get started.   A few things, though, are well documented and with examples in 
the manual (new %magics, aliases, and input filtering).

As I rework ipython, one of my goals is to make a decent writeup of its public 
API, so that users can know exactly where to look for extension points.  Some 
of this is documented here:


(hooks section - due to a Trac bug, the links in the Table of contents don't 
work, just scroll down).

>> If you like this kind of thing, by all means join in: I can use all the
>> helping hands I can get.
> What I've added to my shell is that the debugger uses the same stack dump
> when navigating the stack frames as does the except hook.
> When I added a new way of doing colored terminal output to my packages, I
> noticed that it isn't easy to extend ipython's output, it's either
> pprint.pprint or the default displayhook. I already know Python, so let me
> extend ipython in Python. What I would like to be able to do is the
> following: def mydisplayhook(stream, obj): if isinstance(obj,
> myspecialclass): stream.writeln(...) # my special output return True # tell
> ipython that output has been done return False # tell ipython to give the
> next displayhook a chance
> import ipython ipython.adddisplayhook(mydisplayhook)

Yes, that's basically what the future API will look like.  Currently, you'll 
need to overwrite, using new.instancemethod, the


method, that's all.

> Another idea (that I haven't started to implement yet) is a curses-based
> browser for tabular data that works with generators. I.e. if we had
> generators pwd(), grp(), environ() etc. that yield object with the
> appropriate attributes and a browse function would display the data as a
> curses based table. Paging would be done by fetching the next 40 (or so)
> objects from the generator etc. This might make a good frontend for browse
> SQL result too. If you're interested, I can send you some of my code once
> I'm back from vacation and have access to my machine again (on 1/3)

I'm not a database guy, but this is partly why this discussion is best held 
on-list: there may be other users here who are into that line of work.  I 
encourage you to subscribe (you have to for posting, spam was otherwise out of 
control), the volume is quite low and spam is zero.

Best regards,


More information about the IPython-user mailing list