Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #45324

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

Show key headers only | View raw

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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Debugging difficulty in python with __getattr__, decorated properties and AttributeError. "Mr. Joe" <titanix88@gmail.com> - 2013-05-03 05:34 +0600
  Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-03 00:20 +0000
    Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. "Mr. Joe" <titanix88@gmail.com> - 2013-05-03 13:52 +0600
      Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-04 06:29 +0000
        Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. "Mr. Joe" <titanix88@gmail.com> - 2013-05-14 21:09 +0600
        Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. dieter <dieter@handshake.de> - 2013-05-15 08:15 +0200
        Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. "Mr. Joe" <titanix88@gmail.com> - 2013-05-15 22:38 +0600
    Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError. dieter <dieter@handshake.de> - 2013-05-04 07:56 +0200

csiph-web