[Python-Dev] Type/class

[Paul Prescod]

Guido van Rossum wrote:
> 
>...
> 
> Good point.  Plain old types currently (in the descr-branch) have a
> readonly dict (using a proxy) and no settable attributes.  I will
> probably give types settable attributes in a next revision, but I
> prefer not to make the type's dict writable -- I need to be able to
> watch the setattr calls so that if someone changes
> DictType.__getitem__ I can change the mp_subscript to a C function
> that calls the __getitem__ method.  

I'm happy to have you look and see if I'm setting something magical. But
if I'm not, I would like you to just add the thing I made to an internal
private dictionary and remember it. I think that's what you are talking
about.

>...
> If you're talking about *instances*: instances of subtypes of built-in
> types have a dict of their own to which you can add stuff to your
> heart's content.  Instances of built-in types will continue not to
> have a dict (it would cost too much space if *every* object had a
> dict, even if it was a NULL pointer when no attrs are defined).

Darn. That *is* what I was hoping for.

There is an implementation that is slowish if you use it, but has little
cost if you don't: keep a big dict mapping object pointers to their
associated dictionaries (if any). For purposes of discussion, call it
sys._associations. Then have the getattr on "PyObject" look in this dict
of dicts for attributes that it can't otherwise find, and setattr
construct dictionaries in the dict of dicts if necessary.

That's the usual workaround anyhow so this would be a nicer syntax and a
more orthoganal model.

Price: a hasattr that would return false or getattr that would raise
AttributeError would be a little slower. They would have to check the
dictionary of dictionaries before deciding that they really don't have
the attribute.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook