New PEP: Attribute Access Handlers

[Martijn Faassen]

Paul Prescod <paul at prescod.net> wrote:
[snip]
> 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.

Thinking all of this through independently, I reached the same type of
implementation strategy as you do in your PEP, i.e. something like this:

def getattr(obj, name):
    try:
        found = normal_lookup(obj, name)
        # change start
        if type(found) == types.GetterType:
            return found.get()
        # change end 
        return found
    except NotFound:
        return obj.__getattr__(name)

def setattr(obj, name, value):
    # change start
    if hasattr(obj, 'I_have_computed_attributes'):
        found = lookup_existing_attribute(obj, name)
        if type(found) == types.SetterType:
            found.set(value)
            return
    # change end
    normal_set(obj, name, value)

A difference however is that the attribute handler object is like a method
object, but a special object defining get() and set() (and del()) methods.
This object can delegate to the appropriate __attrget_XXX__ or
__attrset_XXX__ methods on the object that's being manipulated.

As soon as a __attrset_XXX_, or __attrget_XXX__ method is detected during
construction, it is checked whether a handler object for XXX already exists; if
so, the method objects in there will be replaced with these (this to 
take care of inheritance. would it?). Otherwise, a new attribute object
for XXX will be created and the right methods be placed in there.

My apologies if I'm repeating what someone else already said.

Regards,

Martijn     
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?