RetroSearch Browse

Mon Dec 8 05:30:06 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-December/040818.html

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?  Seems sensible enough to me, but Greg Ewing seemed to have
some other use in mind for it...

Cheers,
mwh

-- 
6. The code definitely is not portable - it will produce incorrect 
   results if run from the surface of Mars.
               -- James Bonfield, http://www.ioccc.org/2000/rince.hint

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-December/040818.html below:

[Python-Dev] are CObjects inherently unsafe?