Michael Hudson wrote: > Jim Fulton <jim at zope.com> writes: > > >> > (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. > > > The desc field in a CObject. > > >>I don't really remember what the description was for. I also >>don't have the original email. > > > http://mail.python.org/pipermail/python-dev/2003-December/040702.html > > >>>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. :) > > > Good :-) > > >> > 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. > > > I feel a retcon coming on. > > >>>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. > > > Right. What should we use as the description object? A good old C > string? Probably. I don't have a strong opinion on it. 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