At 04:14 AM 6/10/2007 +0300, Eyal Lotem wrote: >On 6/10/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > At 12:23 AM 6/10/2007 +0300, Eyal Lotem wrote: > > >A. It will break code that uses instance.__dict__['var'] directly, > > >when 'var' exists as a property with a __set__ in the class. I believe > > >this is not significant. > > >B. It will simplify getattr's semantics. Python should _always_ give > > >precedence to instance attributes over class ones, rather than have > > >very weird special-cases (such as a property with a __set__). > > > > Actually, these are features that are both used and desirable; I've > > been using them both since Python 2.2 (i.e., for many years > > now). I'm -1 on removing these features from any version of > Python, even 3.0. > >It is the same feature, actually, two sides of the same coin. >Why do you use self.__dict__['propertyname'] when you can use >self._propertyname?
Because I'm *not writing this by hand*. I'm using descriptors that know what attribute name they're responsible for, and do the access directly. >Why even call the first form, which is both longer and causes >performance problems "a feature"? If you don't understand that, IMO you don't yet understand enough about the descriptor architecture to be proposing changes to it. > > Note, by the way, that if you want to change attribute lookup > > semantics, you can always override __getattribute__ and make it work > > whatever way you like, without forcing everybody else to change > *their* code. >If I write my own __getattribute__ I lose the performance benefit that >I am after. Not if you write it in C. >I do agree that code shouldn't be broken, that's why a transitional >that requires using __fastlookup__ can be used (Unfortunately, from >__future__ cannot be used as it is not local to a module, but to a >class hierarchy - unless one imports a feature from __future__ into a >class). I have no idea what you're talking about here. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com