> > Indeed, CObjects seem fundamentally dangerous to me, unless > > the modules which create and use them are extremely careful > > to make sure they can tell whether they've got the right > > kind of CObject. >> > Well, the right *CObject* -- it's CObject identity that matters. I seem to recall that the CObject design contains a feature to avoid using the wrong CObject, but it's not used by any of the CObject implementations in the standard library, and the CObject docs don't describe how it's meant to use (they were clearly reverse-engineered from the code). Several early checkin messages of cobject.c mention Jim Fulton as the author, so maybe we could ask him. (I'm cc'ing Jim in case he remembers the true intention for the description; he might also know whether Zope 2 still uses it; I can only check Zope 3, and it doesn't.) But even without Jim's confirmation, ISTM from memory and looking at the source that the 'desc' field (which stands for description) was intended as a clue that could be checked by the user of a C Object to verify it had gotten the right one: in a shared header (needed anyway to describe the layout of the struct pointer contained in the C Object) you could define a magic word or a magic string value that would be stored as the description, and the users would check that value before believing the struct pointer. Unfortunately the same CObject version that introduced the description field also introduced the convenience function PyCObject_Import(), which doesn't return the description, and returns the void pointer contained in the CObject without returning the CObject itself, leaving its caller without a clue about the description... Anyway, I think it can be fixed by starting to use the description field and adding a new convenience C API, perhaps named PyCObject_ImportEx(), whch takes a description and checks it. We should try to standardize on what kind of thing to use as the description -- if we use a magic word, PyCObject_ImportEx() should do a simple compare, but if we use a string, it should do a strcmp(). Or the API could simply return the description into an output parameter, making the caller responsible for doing the checking. And the docs should be updated to explain the description better (currently at one point the description is called "extra callback data for the destructor function" which seems a rather odd feature). --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