git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] C API changes


On 11/26/2018 7:08 PM, Larry Hastings wrote:
> On 11/23/18 5:15 AM, Armin Rigo wrote:
>> Also FWIW, my own 2 cents on the topic of changing the C API: let's
>> entirely drop ``PyObject *`` and instead use more opaque
>> handles---like a ``PyHandle`` that is defined as a pointer-sized C
>> type but is not actually directly a pointer.  The main difference this
>> would make is that the user of the API cannot dereference anything
>> from the opaque handle, nor directly compare handles with each other
>> to learn about object identity.  They would work exactly like Windows
>> handles or POSIX file descriptors.
> 
> Why would this be better than simply returning the pointer? Sure, it 
> prevents ever dereferencing the pointer and messing with the object, it 
> is true.? So naughty people would be prevented from messing with the 
> object directly instead of using the API as they should.? But my 
> understanding is that the implementation would be slightly 
> slower--there'd be all that looking up objects based on handles, and 
> managing the handle namespace too.? I'm not convinced the nice-to-have 
> of "you can't dereference the pointer anymore" is worth this runtime 
> overhead.
> 
> Or maybe you have something pretty cheap in mind, e.g. "handle = pointer 
> ^ 49"?? Or even "handle = pointer ^ (random odd number picked at 
> startup)" to punish the extra-naughty?

I thought the important part of the proposal was to have multiple 
PyHandles that point to the same PyObject (you couldn't "directly 
compare handles with each other to learn about object identity"). But 
I'll admit I'm not sure why this would be a win. Then of course they 
couldn't be regular pointers.

Eric