[IPython-user] Re: Question about IPython
davin at eztradelive.com
Thu Mar 11 14:35:28 CST 2004
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
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 : 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
> 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.
More information about the IPython-user