Re: Proto-PEP: Redesigning extension module loading

On 3 March 2015 at 00:21, Petr Viktorin <[email protected]> wrote:
>>>>> We should expose some kind of API in importlib.util (or a better place?)
>>>>> that
>>>>> can be used to check that a module works with reloading and
>>>>> subinterpreters.
>>>>
>>>>
>>>> What would such an API actually check to verify that a module could be
>>>> reloaded?
>>>
>>> Obviously we can't check for static state or object leakage between
>>> subinterpreters.
>>> By using the new API, you promise that the extension does support
>>> reloading and subinterpreters. This will be prominently stated in the
>>> docs, and checked by this function.
>>> For the old API, PyModule_Create with m_size>=0 can be used to support
>>> subinterpreters. But I don't think the language in the docs is strong
>>> enough to say that m_size>=0 is a promise of such support.
>>
>> Ah, I wasn't clear in terms of "check" or "test" when I mentioned this
>> - I was literally referring to something that could be run in test
>> suites to try these things and see if they worked or not, rather than
>> to a runtime "can I reload this safely?" check. "Try it and see" is
>> likely to be a better approach to take there.
>
> Hm, how would such a test work?
> A function that takes a piece of code (like timeit does), runs it in a
> new subinterpreter, and check for leaks? Or runs it in a new process
> and verifies no objects remain after PyFinalize?
> That seems way out of scope here.

Yeah, I was thinking along the lines of some of the tests in
_testembed.c. However, you're right it shouldn't be a requirement of
the PEP.

> I think this draft is fine now so I'll start working on the implementation:

Sounds good. Brett, could you do the honours and post this latest
draft at the same time you post the PYO removal PEP?

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia