> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4