[IPython-dev] Magics, aliases, namespaces

Ville Vainio vivainio at kolumbus.fi
Tue Jun 29 08:13:40 EDT 2004


> 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

Shouldn't this be rather simple, or am I misunderstanding something? 
Just implement only one function in Magic, e.g. magic_execute. Then the 
"magic handler" would return the command to be executed as

"magic_execute(real_magic_name, rest_of_the_line)".

magic_execute would then do whataver it wants to do, probably just 
lookup real_magic_name in some dictionary and pass the rest_of_the_line 
to it as args.

Obviously the first implementation of all the magics could be exactly 
the current ones via some portability bridge class...

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

Perhaps I might be able to put in some hours every now and again. I'm 
not sure how "serious" commitment I can make, but you could nevertheless 
put up some "needs to be done, and how to go about it" tasks to the 
ipython web page / wiki / whatever. I'll see if there's something I 
would like to do.

BTW, one thing that you could even do for the next release: magics for

@bookmark  <bookmarkname>   (associate <bookmarkname> with current dir)

@cdb <bookmarkname>     (cd bookmark, change to dir identified by 
<bookmarkname>

These bookmarks would of course be persistent, stored in the user's 
ipython dir on exit and read in on startup. In fact a lightweight 
persistence system might be implemented, where a dictionary (accessible 
by global persiststore() function) is pickled out on exit, and pickled 
in on startup. Bookmarks could be stored there, and other data that the 
users may want to store. Pickling is pretty safe as long as you use 
standard python types, so name changes won't break the compatibility.

BTW, I'm going to post a little bit of PR/advocacy brainstorming on 
c.l.py soon, probably today. I'm having some wild ideas again ;-).




More information about the IPython-dev mailing list