Home Original page

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

Bob Ippolito bob at redivi.com
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
More information about the Python-Dev mailing list