[Python-Dev] Type/class (original) (raw)

Paul Prescod paulp@ActiveState.com
Thu, 10 May 2001 17:26:43 -0700

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