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

[Walter Dörwald]

Fernando Perez wrote:

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

OK, I'm subscribed to the list now.

> 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 won't need every feature that IPython offers, and once the step from 
using displayhook+excepthook to subclassing code.InteractiveConsole is 
done, the rest seems to be pretty straightforward.

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

I fear that this is more a feature of Python than of the way IPython is 
designed.

> 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

I like the decision to go with plain Python files for configuration.
Also being able to extend IPython with hooks written in Python sounds good.

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

OK, but that replaces the complete output function. What I'd like to 
have is a way to replace the output function only for certain types of 
objects. For this I've been using the following decorator that allows 
installing a function as a "cooperative displayhook":

def asdisplayhook(function):
    oldhook = sys.displayhook
    def hook(obj):
       result = function(obj)
       if result is not None and not result:
          result = oldhook(obj)
          return result
    hook.__dict__.update(function.__dict__)
    hook.__doc__ = function.__doc__
    hook.__name__ = function.__name__
    sys.displayhook = hook
    return function

Installing a hook that only changes the output of ints then works like this:

@asdisplayhook
def inthook(obj):
    if isinstance(obj, int):
       print "%d (0%o, 0x%x)" % (obj, obj, obj)
       return True
    return False

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

This has nothing to do with databases per se. Just think of the output 
of %whos, which would be a candidate for this functionality.

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

I'm subscribed now.

Bye,
    Walter Dörwald