[IPython-dev] Tests for prefilter

Brian Granger ellisonbg.net at gmail.com
Wed Feb 28 17:36:43 EST 2007


Dan,

I haven't had a chance to look at the attachment yet, but it is great
you've started looking at this.

I have been sick since getting back to Boulder on Monday, so I haven't
been checking email.  I will probably feel good enough to work
tomorrow - I'll send you a longer reply then.

Cheers,

Brian

On 2/28/07, Dan Milstein <danmil at comcast.net> wrote:
> ipython-folk,
>
> Okay, as promised, here's a script which runs fairly exhaustive tests
> on the input prefiltering.
>
> Comments in the code, but some highlights:
>
>   - Run it as python test_prefilter.py (i.e. *not* using ipython)
>
>   - It's quiet by default, but you can pass in -v to get dots
>
>   - I'm only testing to make sure the right handle_X methods get
> called.  I am *not* testing those methods at all.  In fact, I swap
> them out as part of the tests.
>
>   - However, that leaves plenty to test ;-).  Basically, it's making
> sure that the right combination of %options, namespace contents and
> input patterns trigger the right expansions.  The gorgeous mess that
> is _prefilter().  136 tests total.
>
>   - I found a bunch of things which look like bugs, which I'm listing
> below.  I am *not* having the tests complain about those yet.  I'm
> wanting it to quietly succeed so that I can use it to test a rewrite
> of prefiltering.  If you'd like the failing tests turned back on, I
> can do that pretty easily.  (I left XXX comments in the code where
> tests can/should be added back in).
>
> Bugs / Questions
> ================
>
>   1) Even with %autocall off, '/', ',' and ';' should trigger
> autocalls. Does not work. (I asked about this Monday)
>
>   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.
>
>   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).
>
>   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.
>
> 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)'.
>
>
> That's what I've got...
> -Dan
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>
>



More information about the IPython-dev mailing list