[Import-SIG] Proto-PEP: Redesigning extension module loading

[Brett Cannon]

The PEP has been committed and assigned number 489 (it will eventually show
up at https://www.python.org/dev/peps/pep-0489 once the PEPs are
re-generated).

Petr, from now on you can send changes to peps at python.org. Make sure you
attach them to your email as a diff against https://hg.python.org/peps .
The next steps are to post to python-dev saying the PEP exists and to
discuss it here on the import-sig. You should also eliminate all XXX
references in the PEP.

On Tue, Mar 3, 2015 at 8:01 AM Brett Cannon <brett at python.org> wrote:

> Yeah, I can assign it a number and get it committed when I add my PYO PEP.
>
> On Tue, Mar 3, 2015 at 7:44 AM Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 3 March 2015 at 00:21, Petr Viktorin <encukou at gmail.com> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20150313/6ee3e7e6/attachment.html>