Why property works only for objects?

[Alex Martelli]

Michal Kwiatkowski <ruby at no.spam> 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