"Mr. Joe" <titani...@gmail.com> writes:
> ...
> Sorry for digging this old topic back. I see that my "'property' does not
> play well with polymorphic code" comment generated some controversy. So
> here's something in my defense:
I did not intend to "attack" you.
> ...
> Yes, I like decorators and descriptors. I also like the ability to create a
> "virtual property" in a python class by binding a bunch of methods as
> setter/getter. But I find the implementation of this "virtual property
> feature" a bit awkward sometimes - every time I need to override a
> getter/setter in a child class, I need to decorate them again. Some of you
> may like this "explicitness", but I don't.
True, I have been hit by this, too - not with "property" but with
other decorators (those for caching).
But, after reflection, I came to the conclusion that I should be
happy with this feature:
If Python would automatically redecorate overridden methods in a derived
class, I would have no control over the process. What if I need
the undecorated method or a differently decorated method (an
uncached or differently cached method, in my case)?
Your getter/setter use case can quite easily be solved
with a class "DelayedMethodAccessor":
class DelayedMethodAccess(object):
"""
def __init__(self, name): self.__name = name
def __call__(self, inst, *args, **kw):
return getattr(inst, self.__name)(*args, **kw)
You can then use:
prop = property(DelayedMethodAccess("<getter_name>"), ...)
Or define a new decorator "property_by_name" and then
use
prop = property_by_name("<getter_name>", ...)
Of course, this requires that the property name and the getter/setter names
differ, but this should be naturally enough.
Python's current behavior is very natural once you know that
decorators are just syntactic sugar and
@<decorator_expression>
def <f>...
simply means:
def <f>...
f = <decorator_expressen>(f)
True, this is no perfect fit for all use cases - but
such a fit (if it existed at all) would have to be so complex
that only experts could understand it.
--
http://mail.python.org/mailman/listinfo/python-list
