[IPython-dev] Macro redesign
Ville M. Vainio
vivainio at gmail.com
Fri May 4 01:47:15 EDT 2007
On 5/3/07, Robert Kern <robert.kern at gmail.com> wrote:
> > This would allow using macros for many things you need to write
> > functions, magics or aliases now.
> That would pretty drastically change the semantics of macros. Macros are
> currently simply executed in the interpreter's namespace. If you ultimately turn
Yeah, and macro's would still be strings that are executed in the
interpreter's namespace (with the addition of the argument string).
It's just that calling happens through () operation.
> The normal way you make macros would be gone, too. Macros are made from commands
> that you've already executed, but $m_arg doesn't exist until you've made it into
> a macro. You might be able to implement your way around it, but you would be
> replacing one small special case (which isn't so special in the core1
> refactoring) into a bunch of special cases.
No, you would create the macro in the normal way. Then you %edit it
and %store it to "generalize", if you want. Say that you did an %imp
macro, you'll would probably test it like:
[~]|3> import os
<4> <module 'os' from 'C:\Python25\lib\os.pyc'>
[~]|5> macro imp 3-4
Macro `imp` created. To execute, type its name (without quotes).
Then, you just do %edit imp, and replace 'os' with $m_arg everywhere.
Now, the only way to configure how a macro behaves is to alter global
variables which kinda sucks.
> Fernando and I had considered implementing macros by expanding them in the
> "translation" phase (a la autocall), but we rejected it for some reason.
Yeah, I also thought of expanding it in prefilter to
_ip.macrocall(mymacro) but just doing mymacro() is IMO cleaner. We
just need to pass the current ipapi object to the macro, and that's
something IpyAutocallMixin (IpyObjectMixin?) could do.
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
More information about the IPython-dev