I have to agree with you. If removing support for self.__dict__['propertyname'] (where propertyname is also the name of a descriptor) is the price to pay for significant speedup, so be it. People doing that are asking for trouble anyway!
<br><br><div><span class="gmail_quote">On 10/06/07, <b class="gmail_sendername">Eyal Lotem</b> <<a href="mailto:eyal.lotem@gmail.com">eyal.lotem@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/10/07, Phillip J. Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>> At 12:23 AM 6/10/2007 +0300, Eyal Lotem wrote:<br>> >A. It will break code that uses instance.__dict__['var'] directly,
<br>> >when 'var' exists as a property with a __set__ in the class. I believe<br>> >this is not significant.<br>> >B. It will simplify getattr's semantics. Python should _always_ give<br>> >precedence to instance attributes over class ones, rather than have
<br>> >very weird special-cases (such as a property with a __set__).<br>><br>> Actually, these are features that are both used and desirable; I've<br>> been using them both since Python 2.2 (i.e., for many years
<br>> now). I'm -1 on removing these features from any version of Python, even 3.0.<br><br>It is the same feature, actually, two sides of the same coin.<br>Why do you use self.__dict__['propertyname'] when you can use
<br>self._propertyname?<br>Why even call the first form, which is both longer and causes<br>performance problems "a feature"?<br><br><br>> >C. It will greatly speed up instance variable access, especially when
<br>> >the class has a large mro.<br>><br>> ...at the cost of slowing down access to properties and __slots__, by<br>> adding an *extra* dictionary lookup there.<br>It will slow down access to properties - but that slowdown is insignificant:
<br>A. The vast majority of lookups are *NOT* of properties. They are the<br>rare case and should not be the focus of optimization.<br>B. Property access involves calling Python functions - which is<br>heavier than a single dict lookup.
<br>C. The dict lookup to find the property in the __mro__ can involve<br>many dicts (so in those cases adding a single dict lookup is not<br>heavy).<br><br>> Note, by the way, that if you want to change attribute lookup
<br>> semantics, you can always override __getattribute__ and make it work<br>> whatever way you like, without forcing everybody else to change *their* code.<br>If I write my own __getattribute__ I lose the performance benefit that
<br>I am after.<br>I do agree that code shouldn't be broken, that's why a transitional<br>that requires using __fastlookup__ can be used (Unfortunately, from<br>__future__ cannot be used as it is not local to a module, but to a
<br>class hierarchy - unless one imports a feature from __future__ into a<br>class).<br>_______________________________________________<br>Python-Dev mailing list<br><a href="mailto:Python-Dev@python.org">Python-Dev@python.org
</a><br><a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a><br>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com">
http://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com</a><br></blockquote></div><br><br clear="all"><br>-- <br>Gustavo J. A. M. Carneiro<br>INESC Porto<br>"The universe is always one step beyond logic." -- Frank Herbert