Erm... might I suggest... (Re: New PEP: Attribute Access Handlers)

[Paul Prescod]

Michal Wallace wrote:
> 
> ....
> 
> The two dict idea does make sense. You could have a __handler__ dict,
> and then the normal __dict__. __dict__ would work as today, containing
> normal values. __handler__ would contain accessor methods, marked as
> being the special type to distinguish them from any other
> methods... Or something else.

Why do accessor methods in __handler__ have to be differentiated if the
only thing in __handler__ is accessor methods?

> The "something else" could be any number of things:
> 
> 1. "None", in which case you go look up the value again in __dict__
>    (which I'd guess is a performance issue to your way of thinking)

I'm not sure if I follow. Let's say that I have a hundred attributes on
an object, and one computed attribute. Are you saying that I would have
two dictionaries with a hundred entries each? 99 would be null in the
__handler__ dictionary?

> 2. A reference to the same value in "dict". This would mean you'd
>    have to update both dicts, and keep them in sync.

Same question.

> 3. A reference to a "default" accessor method (builtin), which
>    probably looks pretty much like the current getattr/setattr/delattr.

Same question.

> ...
> You'd still have to look up the thing again in the other dict, but
> you'd eliminate. Plus the handler dict could be copied directly when
> inheriting, so it would always be a one step search to get the
> handler, and the handlers would act only on __dict__.

I'm somewhat leery about implementing a different inheritance
implementation than that of Python itself. I have a vague feeling that
there is reason that Guido chose NOT to copy things from one class's
dict to another. Perhaps so you could dynamically re-structure your
class hierarchy.

> I was going to suggest doing this as a mixin class, but the current
> getattr/settattr/delattr doesn't seem to allow it when there's already
> a value in the dict:

Right, I don't think that that behavior is so onerous now, nor in the
proposal. In return for the performance I think it is a small price to
pay. One serious constraint is that I cannot slow down Python! Adding an
attribute handler to a class should have as little performance impact as
is humanly possible.

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