[IPython-dev] Tests for prefilter
ellisonbg.net at gmail.com
Wed Feb 28 17:36:43 EST 2007
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.
On 2/28/07, Dan Milstein <danmil at comcast.net> wrote:
> 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...
> IPython-dev mailing list
> IPython-dev at scipy.org
More information about the IPython-dev