Autocall fails if first function argument begins with "-" or "+

[ipython]

Original Launchpad bug 315706: https://bugs.launchpad.net/ipython/+bug/315706
Reported by: dmuders (Dirk Muders).

Auto parentheses fail if the first argument of a function begins with "-" or "+". Thus these examples fail:

%autocall 2
def f(a):
    print a

f -1

f +1

The reason is the re_exclude_auto in prefilter.py which reads

re_exclude_auto = re.compile(r'^[,&^\|\*/\+-]'
                                                   r'|^is |^not |^in |^and |^or ')

in v0.9.1. It appears that this line had been changed at some point after v0.6.2 to also catch operators. However, "-" and "+" can be used with numbers as shown above. Changing the line to

re_exclude_auto = re.compile(r'^[,&^\|\*/]'
                                                   r'|^is |^not |^in |^and |^or ')

fixes the problem but I do not know if something else was intended by adding "+-". If so, then this would need to be caught in a different way.

[ipython]

[ LP comment 1 by: Fernando Perez, on 2010-04-25 01:48:04.569902+00:00 ]

No, see this comment in the code:

# RegExp to exclude strings with this start from autocalling.  In
# particular, all binary operators should be excluded, so that if foo is
# callable, foo OP bar doesn't become foo(OP bar), which is invalid.

Since any callable X could potentially also implement arithmetic, so that

X+1

is as valid as (and different from!):

X(1)

We can't autocall on any binary operator.

[ipython]

[ LP comment 2 by: Dirk Muders, on 2010-04-26 07:54:38.604015+00:00 ]

I understand that argument. In our application we have created a user CLI based on IPython, partially because of being able to omit the parentheses. This makes it easier for users who are unfamiliar with Python but who have used other interfaces that do not need the parentheses. The case with signs (of course mostly the "-" sign) as first characters often occurs in our interface, hence the default IPython behavior breaks the general behavior of our interface and is thus undesirable. We are working with a locally modified version of IPython, but it would be nice to have an "official" switch to choose between the two options.

[ipython]

[ LP comment 3 by: Fernando Perez, on 2010-04-26 19:21:31.005203+00:00 ]

Well, if you are embedding IPython yourselves, you can try doing something like (this is code for trunk, the imports will be slightly different for 0.10):

import re
from IPython.core import prefilter

prefilter.re_exclude_auto = re.compile('your regexp here')

# rest of your code...

Let me know if this works for you. If it does what you need OK, you have a workaround for now, and I'll then refactor the code to have an official API for this.

I've reopened the bug so it stays tracked.

[ipython]

[ LP comment 4 by: Dirk Muders, on 2010-04-27 07:23:54.060105+00:00 ]

We are using IPython directly and we are currently working with a version that we edited in prefilter.py. Next time we upgrade IPython we would have to re-introduce this modification. For the time being we can work this way.

[ipython]

[ LP comment 5 by: Fernando Perez, on 2010-04-27 18:08:52+00:00 ]

OK. Since the upcoming 0.11 release is going to be somewhat of a
'tech preview' (many apis will change), when we put it out we're going
to ask for a lot of feedback from anyone making embedded uses of it.
At that point, we can look at a good api for this (and possibly other
filtering-related things).

Do ping us to remind us when the discussion on api requests comes up,
we want feedback from embedded users on all possible needs.

Cheers,

f

[minrk]

@fperez, from reading the discussion, it seems like this is a 'working as intended' thing. Or do we want to keep it open as a feature request for optional disabling of autocall protection of binary operators?

[bfroehle]

Sounds like this should just get closed, although I did whip up a proof-of-concept which makes the regular expression configurable.

[fperez]

I'm not opposed to making that a configurable. Just the regexp pattern, which is simply a string, can be configurable by the users. If they pass a messed-up regexp that leads to non-sensical behavior, it's their own fault. I expect very few people would use this, but for some such as the OP, it could be a useful knob to tweak without having to monkeypatch us.

[bfroehle]

Should I open a pull request for https://github.com/bfroehle/ipython/compare/_81_autocall_exclude_configurable ?

[fperez]

This will be closed by #1713, in the sense that users are now able to configure this behavior. We won't change our defaults, but now it's a trivial user-facing change.