[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