[IPython-dev] Regression bug in 0.8.x input filtering

[Fernando Perez]

On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:
> Hmm.  I can, I think without too much pain, force whitespace between
> the possible magic/alias/autocall term and the rest of the line, but
> I am just a bit hesitant, because I think that's sort of new
> behavior.  The old pattern matching was very, very hard to fully
> comprehend, but I don't think that's what it did (at least, not in
> general).  I mean, if this is a regression, clearly it did
> *something* like that, but I'd like to fully understand it before I
> make a serious change like that.
>
> (Or maybe people like Ville's fine, fine idea about getting rid of %r
> as a magic -- IMHO, we're kind of asking for trouble given that
> r'something' is valid python).

Well, I don't see why 'r' as a magic should cause any special problems
that other magics don't have.  All magic calls should have at least
one space between their name and their arguments, just like a normal
shell works:

# This works:
maqroll[~/test]> ls foo*
foo.ipy  foo.py  foo.tpl.txt  foo.txt

# but omitting the spaces makes a shell unhappy:
maqroll[~/test]> lsfoo*
lsfoo*: No match.
maqroll[~/test]> ls'foo*'
lsfoo*: Command not found.


So I don't see anything special in %r, other than its name being a
single letter.  If we delete it, do we somehow want to prohibit
single-letter magic names?  Of course not.

The 'grammar' for magics should be:

[%]name [-options] [args]

where the % is optional only if automagic is on, the space is
mandatory, the argument string is split using the same rules that a
shell uses (we do it via shlex.split), and python variables are
expanded into their string form via $ for convenience.

Since magics are meant for quick control of things, they shouldn't
really be themselves too complicated (monstrosities like %run
notwithstanding).  Ideally, the magic should be a thin, -option
controlled convenience wrapper around a library of normal Python
functions that do the real work.  Said functions could then be used by
code without jumping through as many contortions (with full python
types for inputs as well as regular keywords),  and have a magic for
convenience calling (perhaps only of a simplified form).

The original magics as they are today, with a single argstring, are
somewhat of a historical artifact but they match well traditional
shell behavior, and they are thus fast and convenient for interactive
use.  What we need to do is to make it easier to integrate such
convenience on top of a more robust underlying layer that really uses
the Python language in full.

Cheers,

f