[IPython-dev] Proposed IPython changes

[Fernando Perez]

Hi Tzanko,

Tzanko Matev wrote:
> Hi Fernando,
> 
> I'm going to start implementing the python code plug-in in the notebook
> interface. I plan on using the Shell class from PyCrust. For that I need
> an interpreter class which mimics the behaviour of PyCrust's own. I will
> try to make the needed modifications to InteractiveShell. At first,
> however, I plan to convert make_IPython into a number of smaller
> functions. Then I will start making methods for configuring an
> InteractiveShell instance, that these functions will use instead of
> directly messing with the internals. And after that I will implement
> what is needed for the Shell class of PyCrust.
> 
>>From new_design.pdf I understand that part of the cleanup is a new class
> structure which has a better API. My idea is this: make a class Kernel,
> which will contain all the IPython functionality. Then the class
> InteractiveShell will simply be a terminal interface to Kernel, and the 
> notebook program will be a graphical interface. Kernel should contain
> methods for running code, loading configuration, loading logs, etc. I'm
> not that familiar with the current code base so I don't know how long
> this rewrite would take. For now I will only implement parts that are
> needed for the GUI. Please tell me if you like this idea, and what do
> you think the new class design should be. I want to make the GUI in such
> a way that the transition to the new design be as easy as possible.

Yes, that's roughly what I have in mind for the long-term structure.  Having a 
kernel which only takes commands over a specified channel and returns output 
will also allow in the future the possibility to restart the kernel while 
keeping the user interface active, running a kernel on a remote machine, 
controlling multiple kernels from a single front-end, etc.

Please note that the make_ipython routine is just one monster hack for 
historical reasons.  There is absolutely no clean design reason to have it, 
it's really nothing more than an initializer for the ipython instance, because 
when I started writing ipython, I had my own $PYTHONSTARTUP code which I 
merged with a class-based system (IPP).  The quickest way to merge the two 
codes was to keep the IPP __init__, and then run my $PYTHONSTARTUP script 
after that, having renamed it to make_ipython.  But in reality, the class 
constructor should be just one.

The publicly visible classes live in Shell.py, and currently (because of this 
make_ipython mess) they hold an internal reference to the ipython instance 
returned by make_ipython.  Ultimately all that should go away.

There are two other things which should be cleaned up in this process, so they 
don't get in the way.  These are also historical artifacts from the original 
IPP code, they are just gross misfeatures in the current code:

1. (easy) - the logging system is a class mixin.  It shoulde be a standalone 
system, and iypthon should simply instantiate it once and hold a reference to 
this instance at runtime.  Making it a mixin just creates a namespace mess.

2. (not so easy) - the magics are also a mixin.  The namespace mess is worse 
here, though I've tried to prepare things for separation since long ago.  Now 
all magics refer back to the shell via a self.shell attribute, rather than 
relying on self directly.  This means that once separated, as long as the 
standalone magic system is given a valid self.shell pointer to the ipython 
shell, they should continue to run.

Let me know how this all sounds to you.  I know it will take a bit of time to 
familiarize yourself with the tangled hairball that is the ipython engine, but 
nothing here is particularly hard.

Regards,

f