Guido van Rossum wrote: >>>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. Yup, I'm the one who proposed CObject. > (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.) What "it" are you refering to. I don't really remember what the description was for. I also don't have the original email. > But even without Jim's confirmation, ISTM from memory and looking at > the source that the 'desc' field (which stands for description) I now hate abbreviations like that btw. :) > 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. I vaguely remember that such a clue was one possible application of the extra data. I really imagined that the destructor could need the extra data, but, again, it's been a long time. Too bad there's not a PEP. :) > 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... That's because I don't think that the description was primarily intended as a fingerprint. > 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). I like the idea of adding this use of the description. That is, the description is really a marker, that is obtained from an include file and checked against the value in the CObject. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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