[Python-Dev] Fwd: Instance variable access and descriptors (original) (raw)

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