python 属性 class 命名空间混淆

Question

I am confused about use of property class with regard to references to the fset/fget/fdel functions and in which namespaces they live. The behavior is different depending on whether I use property as a decorator or a helper function. Why do duplicate vars in class and instance namespaces impact one example but not the other?

When using property as a decorator shown here I must hide the var name in __dict__ with a leading underscore to prevent preempting the property functions. If not I'll see a recursion loop.

class setget():
    """Play with setters and getters"""
    @property
    def x(self):
        print('getting x')
        return self._x
    @x.setter
    def x(self, x):
        print('setting x')
        self._x = x
    @x.deleter
    def x(self):
        print('deleting x')
        del self._x

and I can see _x as an instance property and x as a class property:

>>> sg = setget()
>>> sg.x = 1
setting x
>>> sg.__dict__
{'_x': 1}
pprint(setget.__dict__)
mappingproxy({'__dict__': <attribute '__dict__' of 'setget' objects>,
              '__doc__': 'Play with setters and getters',
              '__module__': '__main__',
              '__weakref__': <attribute '__weakref__' of 'setget' objects>,
              'x': <property object at 0x000001BF3A0C37C8>})
>>> 

Here's an example of recursion if the instance var name underscore is omitted. (code not shown here) This makes sense to me because instance property x does not exist and so we look further to class properties.

>>> sg = setget()
>>> sg.x = 1
setting x
setting x
setting x
setting x
...

However if I use property as a helper function as described in one of the answers here: python class attributes vs instance attributes the name hiding underscore is not needed and there is no conflict.

Copy of the example code:

class PropertyHelperDemo:
    '''Demonstrates a property definition helper function'''
    def prop_helper(k: str, doc: str):
        print(f'Creating property instance {k}')
        def _get(self):
            print(f'getting {k}')
            return self.__dict__.__getitem__(k) # might use '_'+k, etc.
        def _set(self, v):
            print(f'setting {k}')
            self.__dict__.__setitem__(k, v)
        def _del(self):
            print(f'deleting {k}')
            self.__dict__.__delitem__(k)
        return property(_get, _set, _del, doc)

    X: float = prop_helper('X', doc="X is the best!")
    Y: float = prop_helper('Y', doc="Y do you ask?")
    Z: float = prop_helper('Z', doc="Z plane!")
    # etc...

    def __init__(self, X: float, Y: float, Z: float):
        #super(PropertyHelperDemo, self).__init__()  # not sure why this was here
        (self.X, self.Y, self.Z) = (X, Y, Z)

    # for read-only properties, the built-in technique remains sleek enough already
    @property
    def Total(self) -> float:
        return self.X + self.Y + self.Z

And here I verify that the property fset function is being executed on subsequent calls.

>>> p = PropertyHelperDemo(1, 2, 3)
setting X
setting Y
setting Z
>>> p.X = 11
setting X
>>> p.X = 111
setting X
>>> p.__dict__
{'X': 111, 'Y': 2, 'Z': 3}
>>> pprint(PropertyHelperDemo.__dict__)
mappingproxy({'Total': <property object at 0x000002333A093F98>,
              'X': <property object at 0x000002333A088EF8>,
              'Y': <property object at 0x000002333A093408>,
              'Z': <property object at 0x000002333A093D18>,
              '__annotations__': {'X': <class 'float'>,
                                  'Y': <class 'float'>,
                                  'Z': <class 'float'>},
              '__dict__': <attribute '__dict__' of 'PropertyHelperDemo' objects>,
              '__doc__': 'Demonstrates a property definition helper function',
              '__init__': <function PropertyHelperDemo.__init__ at 0x000002333A0B3AF8>,
              '__module__': '__main__',
              '__weakref__': <attribute '__weakref__' of 'PropertyHelperDemo' objects>,
              'prop_helper': <function PropertyHelperDemo.prop_helper at 0x000002333A052F78>})
>>> 

I can see the class and instance properties with overlapping names X, Y, Z, in the two namespaces. It is my understanding that the namespace search order begins with local variables so I don't understand why the property fset function is executed here.

Any guidance is greatly appreciated.

Answer 1

I think you're a little astray in construing _x as an "instance property" and x as a "class property" - in fact, both are bound to the instance only, and neither is bound to the other except by the arbitrarily defined behaviour of the method decorated by @property .

They both occupy the same namespace, which is why, though they may represent the same quantity, they cannot share a name for fear of shadowing/confusing the namespace.

The issue of namespaces is not directly connected to the use of the @property decorator. You don't HAVE to "hide" the attribute name - you just need to ensure that the attribute name differs from the name of the method, because once you apply the @property decorator, the method decorated by @property can be accessed just like any other attribute without a typical method call signature including the () .

Here's an example, adjacent to the one you provided, that may help clarify. I define a class, PositionVector below, that holds the x , y and z coordinates of a point in space.

When initialising an instance of the class, I also create an attribute length that computes the length of the vector based on the x, y and z values. Trying this:

import numpy as np

class PositionVector:
    
    def __init__(self, x: float, y: float, z: float) -> None:
        self.x = x
        self.y = y
        self.z = z
        self.length = np.sqrt(x**2 + y**2 + z**2)
        
        
p1 = PositionVector(x = 10, y = 0, z = 0)

print (p1.length)
# Result -> 10.0

Only now I want to change the y attribute of the instance. I do this:

p1.y = 10.0
print (f"p1's 'y' value is {p1.y}")
# Result -> p1's 'y' value is 10.0

Except now, if I again access the length of the vector, I get the wrong answer:

print (f"p1's length is {p1.length}")
# Result -> p1's length is 10.0

This arises because length , which at any given instant depends on the current values of x , y , and z , is never updated and kept consistent. We could fix this issue by redefining our class so length is a method that is continuously recalculated every time the user wants to access it, like so:

class PositionVector:
    
    def __init__(self, x: float, y: float, z: float) -> None:
        self.x = x
        self.y = y
        self.z = z
        
    def length(self):
        return np.sqrt(self.x**2 + self.y**2 + self.z**2)

Now, I have a way to get the correct length of an instance of this class at all times by calling the instance's length() method:

p1 = PositionVector(x = 10, y = 0, z = 0)

print (f"p1's length is {p1.length()}")
# Result -> p1's length is 10.0

p1.y = 10.0
print (f"p1's 'y' value is {p1.y}")
# Result -> p1's 'y' value is 10.0

print (f"p1's length is {p1.length()}")
# Result -> p1's length is 14.142135623730951

This is fine, except for two issues:

1. If this class had been in use already, going back and changing length from an attribute to a method would break backward compatibility, forcing any other code that uses this class to need modifications before it could work as before.

2. Though I DO want length to recalculate every time I invoke it, I want to be able to pick it up and "handle" it like it's a "property" of the instance, not a "behaviour" of the instance. So using p1.length() to get the instance's length instead of simply p1.length feels unidiomatic.

I can restore backward compatibility, AND permit length to be accessed like any other attribute by applying the @property decorator to the method. Simply adding @property to the length() method definition allows its call signature to go back to its original form:

    @property
    def length(self):
        return np.sqrt(self.x**2 + self.y**2 + self.z**2)

p1 = PositionVector(x=10, y=0, z=0)

print(f"p1's length is {p1.length}")
# Result -> p1's length is 10.0

p1.y = 10.0
print(f"p1's 'y' value is {p1.y}")
# Result -> p1's 'y' value is 10.0

print(f"p1's length is {p1.length}")
# Result -> p1's length is 14.142135623730951

At this point, there are no shadowed or "underscored" attribute names, I don't need them - I can access x , y and z normally, and access length as though it were any other attribute, and yet be confident that anytime I call it, I get the most current value, correctly reflective of the current values of x , y , and z . Calling dict on p1 in this state yields:

print(p1.__dict__)
# Result -> {'x': 10, 'y': 10.0, 'z': 0}

There could be use cases where you want to not only calculate length , but also save its value as a static attribute of an instance. This is where you might want to create an attribute and have it hold the value of length every time its calculated. You'd accomplish this like so:

class PositionVector:
    def __init__(self, x: float, y: float, z: float) -> None:
        self.x = x
        self.y = y
        self.z = z
        self.placeholder_attribute_name = None

    @property
    def length(self):
        self.placeholder_attribute_name = np.sqrt(self.x**2 + self.y**2 + self.z**2)
        return self.placeholder_attribute_name

Doing this has no effect whatsoever on the prior functioning of the class. It simply creates a way to statically hold the value of length, independent of the act of creating it.

You don't HAVE to name that attribute anything in particular. You can name it anything you want, except for any other name already in use. In the case above, you can't name it x , y , z , or length , because all of those have other meanings.

For readability, however, it does make sense, and it's common practice, to do the following two things:

1. Make it obvious that this attribute is not meant to be used directly. In the case above - you don't want someone to get the length of the vector by calling p1.placeholder_attribute_name because this is not guaranteed to yield the correct current length - they should use p1.length instead. You indicate that this attribute is not for public consumption with a commonly adopted Python convention - the leading underscore:

    class PositionVector:
        def __init__(self, x: float, y: float, z: float) -> None:
            self.x = x
            self.y = y
            self.z = z
            self._placeholder_attribute_name = None
    
        @property
        def length(self):
            self._placeholder_attribute_name = np.sqrt(self.x**2 + self.y**2 + self.z**2)
            return self._placeholder_attribute_name

2. Use the name of the attribute to convey to anyone reading your code what the attribute actually means. If the attribute is meant to shadow the " length " property - putting length in there somewhere instead of the less helpful placeholder_attribute_name would enhance readability. You could indicate that this shadows length by naming it _length .

In summary:

• Employing the @property decorator does not compel you to use "public" and "private" attribute names - you would only do so if, besides computing your attribute's value with the @property decorated method, you also wanted to save the value of that method's return in a persistent attribute bound to every instance of the class.
• Even when you DO choose to use propertyname in public and _propertyname in private this is not an absolute rule, it is simply a convention adopted in aid of readability.

Answer 2

Thanks to Vin for a nice detailed description of property but it doesn't really answer my question - which could have been worded much more clearly. It shows my confusion.

The fundamental reason for the recursion in setget but not PropertyHelperDemo is that the property methods in setget invoke themselves while the methods in PropertyHelperDemo access the instance __dict__ directly as such:

def _get(self):
        print(f'getting {k}')
        return self.__dict__.__getitem__(k)

This seems rather obvious now. It is apparent that conflicting property and __dict__ attribute names are not prevented and that the resolution order is to look for properties before __dict__ entries.

In other experiments I've found that it's possible to replace an instance method by making an entry of the same name in __dict__ . So the overall resolution sequence remains less than clear (to me.)

Another source of confusion for me is that dir returns a list of names of methods plus __dict__ entries and other attributes, and apparently eliminates duplicates. From the doc :

If the object does not provide dir (), the function tries its best to gather information from the object’s dict attribute, if defined, and from its type object. The resulting list is not necessarily complete, and may be inaccurate when the object has a custom getattr ().

... If the object is a type or class object, the list contains the names of its attributes, and recursively of the attributes of its bases.

... The resulting list is sorted alphabetically.

Interestingly, properties appear in the class __dict__ but not in the instance __dict__ .

Another way to explore is using inspect which does not eliminate duplicates.

>>> p = PropertyHelperDemo(1, 2, 3)
setting X
setting Y
setting Z
>>> 
>>> import inspect
>>> pprint(inspect.getmembers(p))
getting X
getting Y
getting Z
getting X
getting Y
getting Z
[('Total', 6),
 ('X', 1),
 ('Y', 2),
 ('Z', 3),
 ('__annotations__',
  {'X': <class 'float'>, 'Y': <class 'float'>, 'Z': <class 'float'>}),
 ('__class__', <class '__main__.PropertyHelperDemo'>),
 ('__delattr__',
  <method-wrapper '__delattr__' of PropertyHelperDemo object at 0x00000181D14C6608>),
 ('__dict__', {'X': 1, 'Y': 2, 'Z': 3}),
 ('__dir__',
  <built-in method __dir__ of PropertyHelperDemo object at 0x00000181D14C6608>),
...
...
...
>>> pprint(inspect.getmembers(p, predicate=inspect.ismethod))
getting X
getting Y
getting Z
getting X
getting Y
getting Z
[('__init__',
  <bound method PropertyHelperDemo.__init__ of <__main__.PropertyHelperDemo object at 0x00000181D14C6608>>),
 ('prop_helper',
  <bound method PropertyHelperDemo.prop_helper of <__main__.PropertyHelperDemo object at 0x00000181D14C6608>>)]
>>> 

In the first listing we can see the property methods as well as the __dict__ attributes. It's interesting (to me) that the property methods are executed by inspect . We see methods X, Y, Z executed twice because Total also calls them. Properties X, Y, Z and Total are not listed when we filter for methods.

Of course it's a great idea to re-use names like this only if you want to drive yourself and everyone else crazy.

Enough omphaloskepsis, it's time to move on.