New PEP: Attribute Access Handlers

[Christian Tanzer]

Paul Prescod <paul at prescod.net> 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*.

True, but:

- the arguments in your original proposal also apply in the case of
  unrelated gets and sets

- imo, related gets and sets on a particular attribute is a rare
  occurence (e.g., none of the scenarios of the justification in your
  PEP falls in this category)

> > 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.

I'll try to sketch how to implement it in comparison to the proposed
implementation in your PEP (I never yet looked at the Python
implementation). 

- no new object type
- no changes in class construction 
- no changes in instance construction
- property fetching:

  * A "get" proceeds as usual until just before `__getattr__' would be
    could. At this point, the dictionary `__attr_getters__' would be
    checked -- if it contains a get-function for the attribute in
    question, that function is called, otherwise `__getattr__' is
    called as usual.

  * A set proceeds by checking the `__attr_setters__' dictionary.
    If it does not contain a set-function for the attribute in
    question, everything proceeds as it does today. Otherwise that
    function is called.

  * The implementation of delete is basically identical to the 
    implementation of set.

> A counter-proposal isn't complete until it describes the
> interpreter changes in more detail.

Sorry. I didn't intend to make a formal counter proposal -- just point
out that there are other options requiring fewer changes. And I
thought it would be obvious how to change the interpreter -- relative
to your proposal, that is.

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92