[Python-ideas] PEP 451 (import API refactoring) and C extension loading

Nick Coghlan ncoghlan at gmail.com
Sat Nov 2 16:53:22 CET 2013


Eric Snow's PEP 451 that refactors the import plugin API to move more
boilerplate responsibility to the import system has come along nicely,
and is now almost certain to make the beta 1 deadline.

One of the guiding elements of that design has been the discussion we
had a while ago on this list about making more information available
to C extensions about how they're being loaded - the ModuleSpec
objects in PEP 451 are a key piece in fulfilling that goal.

However, I'm *not* confident it's going to be possible to work through
all the issues involved in actually refactoring the dynamic loading
infrastructure to use the new plugin model in the time we have left
before feature freeze, particularly since getting the code aspects of
PEP 451 completely bedded down is going to take some time (e.g. it
opens up additional possibilities for the runpy API), and there are
several other things that still need to happen prior to the beta (like
getting ensurepip committed and completing the follow-on work).

So, here's my current thinking: the PEP 451 refactoring makes it far
more feasible to experiment with alternative C extension loading
techniques through cffi, so I'd like to postpone actually changing the
default extension loading system to Python 3.5. The idea of adding
cffi itself to the standard library has been discussed, in which case
we might even be able to move all of that ugly extension management
code out of C and into Python permanently, rather than just as part of
third party experiments.

Thoughts? (cc'ing Stefan directly, since Cython is the most likely
venue for such experiments)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list