[Python-Dev] Let's update CObject API so it is safe and regular!

[Guido van Rossum]

On Wed, Apr 1, 2009 at 7:58 PM, Larry Hastings <larry at hastings.org> wrote:
> Guido van Rossum wrote:
>> Yeah, any two CAPI objects can be used to play this trick, as long as
>> you have some place that calls them. :-(
>
> FWIW, I can't take credit for this observation.  Neal Norwitz threw me at
> this class of problem at the Py3k sprints in August 2007 at Google Mountain
> View, specifically with curses, though the approach he suggested then was
> removing the CObjects.  Then, Monday night MvL and I re-established the
> problem based on my dim memories.
>
>> So what's your solution? If it was me I'd change the API to put the
>> full module name and variable name of the object inside the object and
>> have the IMPORT call check that. Then you can only have crashes if
>> some extension module cheats, and surely there are many other ways
>> that C extensions can cheat, so that doesn't bother me. :)
>
> My proposed API requires that the creator of the CObject pass in a "type"
> string, which must be of nonzero length, and the caller must pass in a
> matching string.  I figured that was easy to get right and sufficient for
> "consenting adults".

OK, my proposal would be to agree on the value of this string too:
"module.variable".

> Note also this cheap exported-vtable hack isn't the
> only use of CObjects; for example _ctypes uses them to wrap plenty of
> one-off objects which are never set as attributes of the _ctypes module.
>  We'd like a solution that enforces some safety for those too, without
> creating spurious module attributes.

Why would you care about safety for ctypes? It's about as unsafe as it
gets anyway. Coredump emptor I say.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)