[IPython-dev] Magics, aliases, namespaces

Fernando Perez Fernando.Perez at colorado.edu
Mon Jun 28 23:05:07 EDT 2004


Ville Vainio wrote:
> Current ipython seems to "special case" lots of stuff - aliases, magics 
> etc. It would seem to yield itself to a simpler and more extensible 
> architecture, consisting of multple dictionaries, where just the order 
> of search is determined by profile/prefix. All the functionality would 
> just be "pushed" to ipython core, i.e. the objects that represent the 
> functionality are instantiated on "plugins" and they are registered with 
> ipython core. i.e.

[snip many good ideas]

All of this sounds very nice.  Now you know why I need to clean up the 
internals, don't you? :)

Keep in mind that ipython was born as an 'afternoon hack' in late 2001 because 
I was having fun learning python and was procrastinating finishing my thesis. 
  I glued together some code of mine with LazyPython and IPP.  IPP (by Janko 
Hauser) already had a bare-bones magics infrastructure and a basic logger, but 
both had been coded in as mixin classes (they still are).  Besides, I didn't 
know the code at all, so I started by nibbling at the sides, slowly going 
further into the core.

But the overall system is in bad need of a redesign, and much of what you said 
goes exactly in the direction I'd like to take it.  But before we get there, a 
continuosly working system must be kept while cleaning things up.  The 
new_design.pdf document included in the distro is used as a scratchpad for 
these kinds of ideas, I'll probably drop your email wholesale in there so it 
doesn't get lost.

But the order of the day will be more like:

- Make Magic and Logger not be mixins, but without further architectural 
cleanup.  Just pull them out of the main class and make sure everything 
continues to work.  It may be possible to use the new logging package from the 
stdlib, I'm not sure (our logging needs are really simple, so this is no big 
deal).

- Clean up the config system, so that ipythonrc files can be normal python 
code.  Maintain the ability to recursively nest profiles.

- Get rid of ipmaker and roll all that into a proper constructor.

Once this is done, then we can _start_ the kind of proper architectural 
redesign you have in mind, and which I'd love to implement.

If you have some time on your hands, I can obviously use all the help 
available.  IPython is only a nights/weekends project for me, and how much 
time I can devote to it varies a lot.  Hence the rather glacial pace of 
development (the 'famous cleanup' has been coming for a loooong time).

If you feel like you'd like to seriously pitch in, let me know and I can point 
you to specific starting points so we can proceed with some semblance of order.

Best,

f




More information about the IPython-dev mailing list