[IPython-user] Re: Question about IPython

Fernando Perez fperez at colorado.edu
Thu Mar 11 00:01:59 CST 2004

Hi Davin,

I've cc-ed the ipython user list, because I think that for this kind of 
discussion the input of others may be valuable (it also gets it archived for 
future reference).  I'd encourage you to subscribe to the list (if you aren't) 
to keep the discussion thread going there.

Davin Boling wrote:
> Are aliases stored in the accessible namespace? I'm interested in doing 
> something as follows: writing a Python script to automaticly generate an 
> alias for every command in a user's path. This would allow IPython to 
> actually function as (almost) complete shell replacement that I could 
> use in place of bash. After all, there's csh for C users, and I believe 
> there's at least one shell utilizing Perl, so why should I be denied a 
> shell that understands Python?

The current alias mechanism isn't really the most elegant.  An alias named 
'foo' is really a dynamically generated function called magic_foo.  This 
raises several issues for your idea:

1.  If you auto-make an alias called 'alias' by finding such a thing in your 
path, you'll break the alias system itself by overwriting ipython's alias 
creation mechanism.

2.  Any aliases you create will overwrite magic functions of the same name.

3.  It will be dog-slow to create hundreds/thousands of aliases.

To be quite honest, I just didn't ever think of ipython as a full shell 
replacement, but simply as a python interpreter with enough shell-like 
functionality for productive use.

Not that I fundamentally oppose the idea in any way: as long as the shell-like 
features can be added in an optional, unobtrusive manner, which doesn't slow 
down normal python usage, that's fine by me.  In fact, any such features 
would, I think, be implemented via a special profile, just like currently you 
can load numeric, scipy or other extensions via profiles.

But as I outlined above, limitations of the current design would make this 
idea very impractical, to say the least.  Have a look into the code for a 
feel, you can simply type alias?? to see the code, or 'pfile alias' to see the 
whole file.

For this to be done cleanly, at least the following changes would be necessary:

1. Put the aliases in their own namespace, separate from the other magics, to 
avoid name clashes.

2. Make alias creation a much cheaper operation than it currently is.  This is 
doable, the current design is a cute but grossly inefficient and unnecessary 
hack.  The 'new' module would probably be the best way to do it.

3. Implement some form of caching, so that a large number of aliases can be 
stored semi-permanently in your ~/.ipython directory.

With these changes, it would be fairly straightforward to do what you want as 
a profile (which I'd be happy to distribute).  Loading ipython in 'shell' mode 
would then simply require 'ipython -p shell'.  Since profiles are recursive, 
you could define your own profiles which incorporate the shell features in 
addition to anything you may want.

> If I might be so bold as to make a suggestion, adding a commandline 
> option to invoke this sort of behavior automaticly. (-s?) This would 
> allow *any* Python user to use IPython as a replacement for their shell 
> with minimal fuss, and I think this would also greatly expand the 
> interest in this project. Of course, this may also be a deviation from 
> the primary focus of the project, so I understand if this isn't in your 
> best interests. Just thought I'd suggest it at least, because I know I'd 
> use it.

I hope the above comments show you that I'm not against it, but that it's a 
large, non-trivial effort.  Considering that right now it's not at the top of 
my ipython priority list (which unfortunately is rather at the bottom of my 
'master' priority list these days), the chances of it happening soon, done by 
me, are low to none.  But if you feel like tackling it, feel free to send the 
patches:  I'll gladly point you in the right directions in the code, and 
discuss the architectural issues before you start coding.



More information about the IPython-user mailing list