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

Paul Prescod paul at prescod.net
Mon Jul 24 03:55:22 EDT 2000


Greg Ewing wrote:
> 
> ...
> 
> I assume that the main reason for funnelling all three
> accessors through a single function stems from the desire to
> be able to look up the function using an interned string,
> and if it were necessary to turn "foo" into "__get_foo__" etc.
> on the fly, that wouldn't be possible.

You sound like you are on the right track but I don't know what you mean
by the last sentence. If a single dictionary lookup could search for two
values in the same time it takes to look up a single value then the
design would probably be different. Interning was never my concern. Now
I'll add it to my list of concerns. :)

> However, this could be easily dealt with by keeping a cache
> of translations from attribute names to interned accessor names.

I don't see how that helps at all. It's not interning that I'm concerned
about. It's looking things up twice.

If you've got a solution with the features you describe I'm all for it
but I need you to describe the full lookup algorithm. How many lookups
does it take to get a normal attribute that is NOT "handled?" How many
for a handled attribute? How many to set a handled attribute? How many
to set an unhandled attribute? How much book-keeping is required at
object creation time? How dynamic is your proposed solution? Are there
two dictionaries per instance or one? Two dictionaries per class or one?
How does the depth of the class hierarchy affect your solution?

If your proposal has these features:

> 3. Doesn't magically put any names in the class dict that weren't
>    explicitly put there by the programmer.
> 4. As a consequence of 3, doesn't preclude having a real attribute with
>    the same name in either the class or instance dict.

Then I can only presume that you look up the __get_?? method *first*
before falling back to the "real" version. That will slow down plain old
ordinary "gets" when there is no __get_?? method.

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