[Python-Dev] doc for new restricted execution design for Python

Sat Jun 24 12:22:32 CEST 2006

On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> Yep. That API will be used directly in the changes to pymalloc and
>> PyMem_*() macros (or at least the basic idea). It is not *only* for
>> extension modules but for the core as well.
>>>> Existing extension modules and existing C code in the Python 
>> interpreter
>> have no idea of any PyXXX_ calls, so I don't understand how 
>> new API
>> functions help here.
>>>>>> The calls get added to pymalloc and PyMem_*() under the hood, so that
>> existing extension modules use the memory check automatically 
>> without a
>> change. The calls are just there in case some one has some random 
>> need
>> to do their own malloc but still want to participate in the cap. 
>> Plus
>> it helped me think everything through by giving everything I would 
>> need
>> to change internally an API.
>> This confused me a bit, too. It might help if you annotated each of 
> the new
> API's with who the expected callers were:
>> - trusted interpreter
> - untrusted interpreter
> - embedding application
> - extension module

Threading is definitely going to be an issue with multiple 
interpreters (restricted or otherwise)... for example, the PyGILState 
API probably wouldn't work anymore.
-bob