[IPython-dev] Should we disable autocall by default from now on?

Warren Weckesser warren.weckesser at enthought.com
Wed Nov 30 12:50:50 EST 2011

On Wed, Nov 30, 2011 at 5:18 AM, Robert Kern <robert.kern at gmail.com> wrote:

> On 11/30/11 7:07 AM, Fernando Perez wrote:
> > Hi folks,
> >
> > over the years, we've had a number of bug reports that ultimately boil
> > down to ipython doing an extra getattr call on objects at the prompt,
> > such as
> >
> > https://github.com/ipython/ipython/issues/988
> > https://github.com/ipython/ipython/issues/851
> >
> > While this may appear odd, people do have code out there that mutates
> > the state of objects on simple getattr calls, and so *any*
> > introspection on such objects, no matter how carefully done, mutates
> > them.  The last example comes from Traits code, which is famous for
> > having complex semantics attached to attribute access.
> >
> > Since this is a recurring problem, I'm trying to decide whether the
> > convenience of autocall being on by default is worth against the
> > occasional surprise of situations like these.
> >
> > Obviously we'd leave the functionality of autocall as-is, and people
> > could still enable it if they wanted to.  I'm only talking about
> > whether it should be completely off by default.  The reason why
> > defaults matter a lot is that the vast majority of users never ever
> > change them (I've seen countless long-term users with the wrong colors
> > for a light bacgkround, the one default we can't pick for them and
> > that leads to unreadable tracebacks, yet people live with it for
> > years).  So it's up to us to give people defaults that lead to the
> > best experience possible.
> >
> > I personally had always fallen on the side of saying that autocall is
> > a big convenience of ipython, and that code that mutates on simple
> > attribute access is special enough that we shouldn't sacrifice that
> > convenience for most users to accommodate such a special case.
> I don't think it's *that* special of a case. There are all kinds of good
> reasons
> to set up a special case for the first time an attribute is looked up while
> mutating the object to let future lookups go through a different path.
> *Usually*, getting the attribute in the autocall code is innocuous, but
> sometimes it isn't.

I'll second Robert's comment.

Here's a "user story" where the double evaluation of an attribute caused
me headaches until I realized what was happening.

We (Enthought) developed some some classes that provide interfaces to
test equipment (oscilloscopes, power supplies, etc).  By using properties,
we developed interfaces to the instruments that were very easy to use.
For example, a statement such as

   instr.voltage = 5

would cause a command to be sent to the instrument to set the voltage to 5.

   v = instr.voltage

would trigger a query to get the current voltage setting from the
and return it as a floating point value.

Working with such a class from within ipython is slick, but no doubt you
can already see the potential problem.  Using ipython as follows

In  [5]: instr.voltage
Out [5]: 5.0

actually sent the query to the instrument twice.  This can be a relatively
query, because the communication might be over a serial line or GPIB

OK, so it is slower than necessary; that is a minor annoyance.  The real
headache occurred when I was using a property that accessed the error
state of the instrument.  Reading the attribute 'system_error' sent the
appropriate query to the instrument, but that query also caused the
to reset its internal error state.  It took me a long time to figure out
when I intentionally did something wrong, the following

In  [8]: instr.system_error

always resulted in no errors!  Eventually I realized that it was triggering
two queries.  I wasn't aware of autocall at the time, so my solution was to
always use print, e.g.

In  [9]: print instr.system_error

So, there's another "real world" use-case where reading an attribute twice
at the command prompt caused problems.  (Whether that particular attribute
should have been a method instead--e.g. read_and_reset_system_error()--is
a separate topic, but there were good reasons for the property



> I've always been in favor of turning autocall off by default, though I
> can't
> really say that I have a strong argument beyond personal preference. I
> don't
> like to keep two parallel Python syntaxes in my head (and muscle memory!),
> especially when one of them is only informally specified and only works in
> one
> specific environment.
> --
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> enigma
>  that is made terrible by our own mad attempt to interpret it as though it
> had
>  an underlying truth."
>   -- Umberto Eco
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20111130/9bc69531/attachment.html>

More information about the IPython-dev mailing list