Michal Kwiatkowski <[EMAIL PROTECTED]> wrote: ... > > No, the value found in the instance (your second 'else' here) takes > > precedence if the descriptor found in the first 'else' is > > non-overriding. > > Oh, right. My mistake comes from the subtle difference between defining > descriptor as a class and by property() builtin (I've tested only second > option and assumed that descriptor without __set__ cannot be rebinded):
property is always overriding, of course, since type property does have a property.__set__ (which raises an exception if you build the instance of property w/o a setter function). > class non_overriding(object): > def __get__(*a): > return 12 > > class C(object): > x = non_overriding() > y = property(lambda s:23) > > c = C() > > c.x = 4 > print c.x # => 4 > > c.y = 5 # => AttributeError: can't set attribute Right: another example of overriding and nonoverriding descriptors. > IMHO that's not very consistent. How so? Given the lower-level semantics of descriptors (and the distinction between overriding and non), are you suggesting that property should not be a type but a factory function able to return instances of either overriding or non-overriding types? I'm not sure how that complication would make things "consistent" in your view. > Well, probably some code rely on this, > so I just have to live with it. Backwards-incompatible changes can be proposed for Python 3.0, if they lead to a situation that's preferable to what we have now. I just don't see what you mean about "not very consistent" and what you would prefer the language and built-ins to be. Alex -- http://mail.python.org/mailman/listinfo/python-list