[IPython-user] Re: Question about IPython

[Andrew Boling]

Subscribed just now, I used the e-mail address I have all of my other 
mailing list subscriptions on.

At any rate, I know I'm weirdo for wanting to replace /bin/bash with 
iPython, but I've been wanting a shell that uses Python and so far 
iPython seems the closest to having the necessary functionality without 
writing one from scratch. Heck, it's even got its own rc files, so all 
it's missing is the actual filesystem interaction.

Fernando Perez wrote:
> 
> 
> 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:
> 
 > ....

I'm thinking that in light of the above the "sanest" (which isn't saying 
much) method would be to alter the behavior of the shell parser if 
iPython is started with a certain commandline option. I have no problem 
with writing this functionality myself and providing the support for it, 
assuming that everyone is generally okay with the change - it wouldn't 
be interfering with their existing use of iPython unless they explicitly 
turned this behavior on, meaning that everyone is happy.

As it is, sharing the 'global' namespace are two types of commands:
1. iPython commands (they're magicly delicious)
2. Python builtins and modules imported to the global namespace.

With the new option this idea suggests, I propose a third:
3. Shell commands (commands in your PATH)

Every command entered should be screened against all three of these 
before returning an error. I believe the order should be as follows, 
with my reasonings included.

The user types a line of text, hits enter...
1. If the first word matches an alias or magical command, execute the 
iPython command as normal. This gives highest priority to iPython's 
built-in functionality, and also means that it cannot be overridden by 
commands in the PATH or by Python commands.
2. If no matching alias exists, check the first word against commands in 
the PATH. Because the alias check has already been performed, these 
commands would not override iPython aliases. If a match is found, all 
words after the first are arguments to be passed to the first matching 
command.
3. If no matching alias or command in PATH exists, evaluate the entire 
line in Python. I think this step should be last because it allows the 
main Python interpreter to handle the unknown string and print traceback.

This is a completely different way of doing what I described without 
having to rely on the creation of aliases to interact with the shell.

The main disadvantage of the above are the names of shell commands 
overriding the names of functions in the global namespace (with the 
exclusion of iPython commands, which are protected). This will not be 
noticable for the most part - many python statements contain parenthesis 
on the first argument which would prevent a shell command from matching 
as it is, and the Python builtins that do not use parenthesis (print, 
if, for, while, def, class, etc.) generally do not have commandline 
equivilants; shells internally interpret most of those directives.

Here is a problem I *do* see:
In [1]: ps = 47

Since ps matches up with a command in the user's path, the end result is 
that ps gets executed with the arguments "= 47". This is the main 
stumbling block - you can't have objects which are named after existing 
shell commands. At the same time, I don't really see this as a big 
problem either, since you generally wouldn't be using iPython to write 
your serious programs if you're using it as your commandline shell. It 
simply facilitates easy access to Python functionality while accessing 
your system.

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

Yeah, only I'm that much of a nut. >:)

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

Unfortunately, what I just proposed is more of a functionality change to 
the program itself than the original 'alias building' behavior I was 
describing. If I'm not mistaken, I think that would rule profiles out, 
unless you could refine my newest idea or outright can it.


At any rate, let me know what you think about my revised suggestion, as 
I think it neatly circumvents the problems you described with my 
original approach. Also, if anyone has a *better* way of implimenting 
the above or see any obvious problems, by all means comment.