Debugging difficulty in python with __getattr__, decorated properties and AttributeError.

dieter dieter at handshake.de
Wed May 15 02:15:53 EDT 2013


"Mr. Joe" <titanix88 at 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.




More information about the Python-list mailing list