At 04:14 AM 6/10/2007 +0300, Eyal Lotem wrote:

On 6/10/07, Phillip J. Eby 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.