New PEP: Attribute Access Handlers

Paul Prescod paul at prescod.net
Mon Jul 24 02:42:52 EDT 2000


Christian Tanzer wrote:
> 
> ...
>
>   * 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.

That's a good first pass but there are a lot of unresolved issues.

For every "get" failure you do an extra dictionary lookup (even if the
attribute doesn't have handlers). get failures are common in Python
because people does hasattr(x,"y") alot. 
__getattr__ will also take longer to get to until today. 

You won't find a computed attribute until you've gone through the entire
class hierarchy and come up with no value. Even a computed attribute
directly in the instance's __dict__ won't get found until all class's
have been exhausted.

Also an extra dictionary allocation is a non-trivial cost.

Plus, it isn't clear how this dictionary is set up in the first place.
Is it per-class or per-instance? Do runtime assignments change it? Does
it get bigger as the inheritance hierarchy gets deeper?
 
>   * 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.

Okay, so let's say I have a get function but no set function. Won't the
very first "set" put a variable in the dictionary so that future "gets"
will fail according to the algorithm you described?

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




More information about the Python-list mailing list