<br><br><div class="gmail_quote">On Wed, Nov 30, 2011 at 5:18 AM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 11/30/11 7:07 AM, Fernando Perez wrote:<br>
> Hi folks,<br>
><br>
> over the years, we've had a number of bug reports that ultimately boil<br>
> down to ipython doing an extra getattr call on objects at the prompt,<br>
> such as<br>
><br>
> <a href="https://github.com/ipython/ipython/issues/988" target="_blank">https://github.com/ipython/ipython/issues/988</a><br>
> <a href="https://github.com/ipython/ipython/issues/851" target="_blank">https://github.com/ipython/ipython/issues/851</a><br>
><br>
> While this may appear odd, people do have code out there that mutates<br>
> the state of objects on simple getattr calls, and so *any*<br>
> introspection on such objects, no matter how carefully done, mutates<br>
> them. The last example comes from Traits code, which is famous for<br>
> having complex semantics attached to attribute access.<br>
><br>
> Since this is a recurring problem, I'm trying to decide whether the<br>
> convenience of autocall being on by default is worth against the<br>
> occasional surprise of situations like these.<br>
><br>
> Obviously we'd leave the functionality of autocall as-is, and people<br>
> could still enable it if they wanted to. I'm only talking about<br>
> whether it should be completely off by default. The reason why<br>
> defaults matter a lot is that the vast majority of users never ever<br>
> change them (I've seen countless long-term users with the wrong colors<br>
> for a light bacgkround, the one default we can't pick for them and<br>
> that leads to unreadable tracebacks, yet people live with it for<br>
> years). So it's up to us to give people defaults that lead to the<br>
> best experience possible.<br>
><br>
> I personally had always fallen on the side of saying that autocall is<br>
> a big convenience of ipython, and that code that mutates on simple<br>
> attribute access is special enough that we shouldn't sacrifice that<br>
> convenience for most users to accommodate such a special case.<br>
<br>
</div></div>I don't think it's *that* special of a case. There are all kinds of good reasons<br>
to set up a special case for the first time an attribute is looked up while<br>
mutating the object to let future lookups go through a different path.<br>
*Usually*, getting the attribute in the autocall code is innocuous, but<br>
sometimes it isn't.<br></blockquote><div><br><br>I'll second Robert's comment.<br><br>Here's a "user story" where the double evaluation of an attribute caused<br>me headaches until I realized what was happening.<br>
<br>We (Enthought) developed some some classes that provide interfaces to<br>test equipment (oscilloscopes, power supplies, etc). By using properties,<br>we developed interfaces to the instruments that were very easy to use.<br>
For example, a statement such as<br><br> instr.voltage = 5<br> <br>would cause a command to be sent to the instrument to set the voltage to 5.<br>Similarly,<br><br> v = instr.voltage<br><br>would trigger a query to get the current voltage setting from the instrument,<br>
and return it as a floating point value.<br><br>Working with such a class from within ipython is slick, but no doubt you<br>can already see the potential problem. Using ipython as follows<br><br>In [5]: instr.voltage<br>
Out [5]: 5.0<br><br>actually sent the query to the instrument twice. This can be a relatively slow<br>query, because the communication might be over a serial line or GPIB interface.<br><br>OK, so it is slower than necessary; that is a minor annoyance. The real<br>
headache occurred when I was using a property that accessed the error<br>state of the instrument. Reading the attribute 'system_error' sent the<br>appropriate query to the instrument, but that query also caused the instrument<br>
to reset its internal error state. It took me a long time to figure out why,<br>when I intentionally did something wrong, the following<br><br>In [8]: instr.system_error<br><br>always resulted in no errors! Eventually I realized that it was triggering<br>
two queries. I wasn't aware of autocall at the time, so my solution was to<br>always use print, e.g.<br><br>In [9]: print instr.system_error<br><br>So, there's another "real world" use-case where reading an attribute twice<br>
at the command prompt caused problems. (Whether that particular attribute<br>should have been a method instead--e.g. read_and_reset_system_error()--is<br>a separate topic, but there were good reasons for the property implementation.)<br>
<br>Cheers,<br><br>Warren<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I've always been in favor of turning autocall off by default, though I can't<br>
really say that I have a strong argument beyond personal preference. I don't<br>
like to keep two parallel Python syntaxes in my head (and muscle memory!),<br>
especially when one of them is only informally specified and only works in one<br>
specific environment.<br>
<font color="#888888"><br>
--<br>
Robert Kern<br>
<br>
"I have come to believe that the whole world is an enigma, a harmless enigma<br>
that is made terrible by our own mad attempt to interpret it as though it had<br>
an underlying truth."<br>
-- Umberto Eco<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>