[Python-Dev] Type/class

[Guido van Rossum]

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

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