[IPython-dev] Fwd: Tests for prefilter

Brian Granger ellisonbg.net@gmail....
Wed Mar 7 10:54:31 CST 2007


---------- Forwarded message ----------
From: Brian Granger <ellisonbg.net@gmail.com>
Date: Mar 6, 2007 10:27 AM
Subject: Re: [IPython-dev] Tests for prefilter
To: Dan Milstein <danmil@comcast.net>


Dan,

I have gone through your questions about prefilter (see responses
inline below).  I am not the expert here - Fernando and Ville will
have to fill in details.  But, in many cases, my guess is that you are
running up against our lack of tests in the first place.  The miracle
is that this hasn't prevented ipython from being really useful to lots
of people.

One comment that may be a bit controversial.  I do think that moving
forward, we need to get rid of cases in ipython's syntax where there
is ambiguity.  This may (and I think should) mean that certain
features are removed unless we can fully specify their behavior in all
cases and provide full test coverage.  Fernando and Ville, any
comments about this?  My own feeling is that as we refactor prefilter
and friends we should focus on providing a framework that will make it
easy to maintain/extent/test the core features of ipython.

Thoughts?

Brian


> Bugs / Questions
> ================
>
>   1) Even with %autocall off, '/', ',' and ';' should trigger
> autocalls. Does not work. (I asked about this Monday)

>From the docs, it seems like it should work.

>   2) In several places, the prefilter checks for an input line which
> looks like, e.g.:
>
> thing = rhs
>
> And, if it finds it, doesn't try to look up 'thing' as an alias, etc,
> so that a normal python expr won't get shadowed by ipython magic
> bits.  However, in some places, the set of characters which turn off
> the magic bits are: '!=()', and in others, they are '!=()<>'. I
> *think* they should be the same in both places.  See, e.g. line 2121
> v line 2135.  Or, just possibly it should be all python binary ops,
> which is a much bigger list.

Fernando?  Ville?

>   3) Can aliases have '.' in their names?  If so, there's a problem:
> such aliases *do* expand with %autocall off, but they *don't* expand
> when it's on (because of a subtlety of how ._ofind is used or avoided).

I am guessing that we don't have a spec on exactly what can/cannot
appear in alias names.  The same would probably also hold true of
macros.  It would be good to come up with an official spec and write
tests for that.

>   4) More autocall fun -- what should ipython do (with autocall on),
> with the two following (the comments are my understanding of how it's
> supposed to work currently):
>
>  > "abc".join range(4)     # Should *not* autocall and doesn't
>
>  > /"abc".join range(4)    #2 *Should* autocall, but doesn't.

Hmmm.   Fernando, Ville?  Ideas?  What should the behavior be?

> Currently, #1 should *not* autocall the join method, because autocall
> only triggers for things which look like identifiers mixed with '.'.
> Is that, in fact, how the system should work?

> However, #2 also doesn't autocall the join (and it should, I think).
> In fact, it totally blows up -- ipython somehow ends up with a '//'
> at the start of the line and has no idea what to do.  I think I know
> why this is happening.
>
>
>   5) Binary ops and autocall
>
> Autocalling gets turned off for *most* binary operators, so that,
> e.g. 'fun in lst' won't become 'fun(in list)', even if fun is
> callable.   However, it's missing the % operator.  So that, e.g. 'fun
> % s' will become 'fun(%s)'.

Probably, unless there is some wierd reason not.  Fernando and Ville
might be aware of such a reason.


More information about the IPython-dev mailing list