New PEP: Attribute Access Handlers

[Paul Prescod]

Christian Tanzer wrote:
> 
> ...
> In general, get/set/del are not related. For instance:
> 
>     $ dir ~/ttt/ttptools/*/*.py | wc -l
>         426
>     $ grep '  def __setattr__' ~/ttt/ttptools/*/*.py | wc -l
>           5
>     $ grep '  def __getattr__' ~/ttt/ttptools/*/*.py | wc -l
>          44
>     $ grep '  def __delattr__' ~/ttt/ttptools/*/*.py | wc -l
>           0

This statistics are not that meaningful unless those __setattr__ and
__getattr__s are all implementing this convention. Gets and sets on a
*particular attribute* are more likely to be symmetrical and related
than gets and sets *in general*.

> If the performance side of problem 2 is really an issue, move the
> checking of `__attr_setters__/__attr_getters__/__attr_deleters__' from
> `__setattr__/__getattr__/__delattr__' into the interpreter (other
> names for the magic dictionaries might be useful then).

Fine: "move it into the interpreter"? How? The current proposal allows
an optimized implementation in the interpreter. Part of the design is
based on this. A counter-proposal isn't complete until it describes the
interpreter changes in more detail.

I would be happy to allow separate getter/setter/delete methods as long
as they have clear(er) semantics in the face of inheritance and an
efficient implementation. I (or someone) may still come up with a scheme
that balances these goals but right now we don't have such a thing.

-- 
 Paul Prescod - Not encumbered by corporate consensus
New from Computer Associates: "Software that can 'think', sold by 
marketers who choose not to."