<div dir="ltr">Yeah, I can assign it a number and get it committed when I add my PYO PEP.<br></div><br><div class="gmail_quote">On Tue, Mar 3, 2015 at 7:44 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 March 2015 at 00:21, Petr Viktorin <<a href="mailto:encukou@gmail.com" target="_blank">encukou@gmail.com</a>> wrote:<br>
>>>>> We should expose some kind of API in importlib.util (or a better place?)<br>
>>>>> that<br>
>>>>> can be used to check that a module works with reloading and<br>
>>>>> subinterpreters.<br>
>>>><br>
>>>><br>
>>>> What would such an API actually check to verify that a module could be<br>
>>>> reloaded?<br>
>>><br>
>>> Obviously we can't check for static state or object leakage between<br>
>>> subinterpreters.<br>
>>> By using the new API, you promise that the extension does support<br>
>>> reloading and subinterpreters. This will be prominently stated in the<br>
>>> docs, and checked by this function.<br>
>>> For the old API, PyModule_Create with m_size>=0 can be used to support<br>
>>> subinterpreters. But I don't think the language in the docs is strong<br>
>>> enough to say that m_size>=0 is a promise of such support.<br>
>><br>
>> Ah, I wasn't clear in terms of "check" or "test" when I mentioned this<br>
>> - I was literally referring to something that could be run in test<br>
>> suites to try these things and see if they worked or not, rather than<br>
>> to a runtime "can I reload this safely?" check. "Try it and see" is<br>
>> likely to be a better approach to take there.<br>
><br>
> Hm, how would such a test work?<br>
> A function that takes a piece of code (like timeit does), runs it in a<br>
> new subinterpreter, and check for leaks? Or runs it in a new process<br>
> and verifies no objects remain after PyFinalize?<br>
> That seems way out of scope here.<br>
<br>
Yeah, I was thinking along the lines of some of the tests in<br>
_testembed.c. However, you're right it shouldn't be a requirement of<br>
the PEP.<br>
<br>
> I think this draft is fine now so I'll start working on the implementation:<br>
<br>
Sounds good. Brett, could you do the honours and post this latest<br>
draft at the same time you post the PYO removal PEP?<br>
<br>
Regards,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div>