[Python-checkins] peps: Added content. First real version of this PEP (original) (raw)

Wed Mar 23 21:22:47 CET 2011

It is possible (and even relatively common) in Python code and 
in extension modules to "trap" when an instance's client code 
attempts to set an attribute and execute code instead. In other 
words it is possible to allow users to use attribute assignment/
retrieval/deletion syntax even though the underlying implementation 
is doing some computation rather than directly modifying a
binding.
This PEP describes a feature that makes it easier, more efficient
and safer to implement these handlers for Python instances.
   You have a deployed class that works on an attribute named
   "stdout". After a while, you think it would be better to
   check that stdout is really an object with a "write" method
   at the moment of assignment. Rather than change to a
   setstdout method (which would be incompatible with deployed
   code) you would rather trap the assignment and check the
   object's type.
   You want to be as compatible as possible with an object 
   model that has a concept of attribute assignment. It could
   be the W3C Document Object Model or a particular COM 
   interface (e.g. the PowerPoint interface). In that case
   you may well want attributes in the model to show up as
   attributes in the Python interface, even though the 
   underlying implementation may not use attributes at all.
   A user wants to make an attribute read-only.
  def __setattr__( self, name, val ):
     if name=="readonlyattr":
        raise TypeError
     elif name=="readonlyattr2":
        raise TypeError
     ...
     else:
        self.__dict__["name"]=val
This has the following problems:
1. The creator of the method must be intimately aware of whether
   somewhere else in the class hiearchy __setattr__ has also been
   trapped for any particular purpose. If so, she must specifically
   call that method rather than assigning to the dictionary. There
   are many different reasons to overload __setattr__ so there is a
   decent potential for clashes. For instance object database
   implementations often overload setattr for an entirely unrelated
   purpose.
2. The string-based switch statement forces all attribute handlers 
   to be specified in one place in the code. They may then dispatch
   to task-specific methods (for modularity) but this could cause
   performance problems.
3. Logic for the setting, getting and deleting must live in 
   __getattr__, __setattr__ and __delattr__. Once again, this can be
   mitigated through an extra level of method call but this is 
   inefficient.
   def __attr_XXX__(self, op, val ):
       if op=="get":
           return someComputedValue(self.internal)
       elif op=="set":
           self.internal=someComputedValue(val)
       elif op=="del":
           del self.internal
Attribute references of all three kinds should call the method.
The op parameter can be "get"/"set"/"del". Of course this string
will be interned so the actual checks for the string will be
very fast.
It is disallowed to actually have an attribute named XXX in the
same instance as a method named __attr_XXX__.
An implementation of __attr_XXX__ takes precedence over an
implementation of __getattr__ based on the principle that
__getattr__ is supposed to be invoked only after finding an
appropriate attribute has failed.
An implementation of __attr_XXX__ takes precedence over an
implementation of __setattr__ in order to be consistent. The
opposite choice seems fairly feasible also, however. The same
goes for __del_y__.
  name (e.g. XXX, not __attr__XXX__
  method (pointer to a method object
  the I_have_computed_attributes flag up to date as attributes
  are added and removed from the instance's dictionary. This is
  consistent with current Python. If you add a __setattr__ method
  to an object after it is in use, that method will not behave as
  it would if it were available at "compile" time. The dynamism is
  arguably not worth the extra implementation effort. This snippet
  demonstrates the current behavior:
   >>> a().foo=5
2. Assignment to __dict__["XXX"] can overwrite the attribute
   store information away in private __XXX variables
3. An attribute access handler that attempts to call setattr or getattr
   on the object itself can cause an infinite loop (as with __getattr__)
   Once again, the solution is to use a special (typically private) 
   variable such as __XXX.