<br><br><div class="gmail_quote">On Wed, Nov 30, 2011 at 5:18 AM, Robert Kern <span dir="ltr">&lt;<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>&gt;</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>
&gt; Hi folks,<br>
&gt;<br>
&gt; over the years, we&#39;ve had a number of bug reports that ultimately boil<br>
&gt; down to ipython doing an extra getattr call on objects at the prompt,<br>
&gt; such as<br>
&gt;<br>
&gt; <a href="https://github.com/ipython/ipython/issues/988" target="_blank">https://github.com/ipython/ipython/issues/988</a><br>
&gt; <a href="https://github.com/ipython/ipython/issues/851" target="_blank">https://github.com/ipython/ipython/issues/851</a><br>
&gt;<br>
&gt; While this may appear odd, people do have code out there that mutates<br>
&gt; the state of objects on simple getattr calls, and so *any*<br>
&gt; introspection on such objects, no matter how carefully done, mutates<br>
&gt; them.  The last example comes from Traits code, which is famous for<br>
&gt; having complex semantics attached to attribute access.<br>
&gt;<br>
&gt; Since this is a recurring problem, I&#39;m trying to decide whether the<br>
&gt; convenience of autocall being on by default is worth against the<br>
&gt; occasional surprise of situations like these.<br>
&gt;<br>
&gt; Obviously we&#39;d leave the functionality of autocall as-is, and people<br>
&gt; could still enable it if they wanted to.  I&#39;m only talking about<br>
&gt; whether it should be completely off by default.  The reason why<br>
&gt; defaults matter a lot is that the vast majority of users never ever<br>
&gt; change them (I&#39;ve seen countless long-term users with the wrong colors<br>
&gt; for a light bacgkround, the one default we can&#39;t pick for them and<br>
&gt; that leads to unreadable tracebacks, yet people live with it for<br>
&gt; years).  So it&#39;s up to us to give people defaults that lead to the<br>
&gt; best experience possible.<br>
&gt;<br>
&gt; I personally had always fallen on the side of saying that autocall is<br>
&gt; a big convenience of ipython, and that code that mutates on simple<br>
&gt; attribute access is special enough that we shouldn&#39;t sacrifice that<br>
&gt; convenience for most users to accommodate such a special case.<br>
<br>
</div></div>I don&#39;t think it&#39;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&#39;t.<br></blockquote><div><br><br>I&#39;ll second Robert&#39;s comment.<br><br>Here&#39;s a &quot;user story&quot; 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 &#39;system_error&#39; 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&#39;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&#39;s another &quot;real world&quot; 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&#39;ve always been in favor of turning autocall off by default, though I can&#39;t<br>
really say that I have a strong argument beyond personal preference. I don&#39;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>
&quot;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.&quot;<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>