[Python-Dev] Fwd: Instance variable access and descriptors

Phillip J. Eby pje at telecommunity.com
Sun Jun 10 20:08:48 CEST 2007


At 04:14 AM 6/10/2007 +0300, Eyal Lotem wrote:
>On 6/10/07, Phillip J. Eby <pje at telecommunity.com> 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.



More information about the Python-Dev mailing list