[IPython-user] [Python-Dev] a quit that actually quits
walter at livinglogic.de
Mon Jan 2 07:57:09 CST 2006
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
>> 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
> 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:
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 #
>> 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.
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":
oldhook = sys.displayhook
result = function(obj)
if result is not None and not result:
result = oldhook(obj)
hook.__doc__ = function.__doc__
hook.__name__ = function.__name__
sys.displayhook = hook
Installing a hook that only changes the output of ints then works like this:
if isinstance(obj, int):
print "%d (0%o, 0x%x)" % (obj, obj, obj)
>> 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
>> 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.
More information about the IPython-user