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

Guido van Rossum guido@digicool.com
Thu, 10 May 2001 20:57:36 -0500

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

OK, we agree on this one.

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

Personally, if you want this outrageous implementation, you should be paying for it, not the infrastructure. It feels contrary to Python's treatment of objects. I don't like elaborate workarounds in the implementation like this -- probably because the performance model becomes muddy.

--Guido van Rossum (home page: http://www.python.org/~guido/)