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

[Fernando Perez]

[ 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:

http://projects.scipy.org/ipython/ipython/wiki/RefactoringIPython

(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

__IPYTHON__.outputcache.display

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,

f