[Import-SIG] PEP 489: Multi-phase extension module initialization; version 5
encukou at gmail.com
Thu May 21 02:49:30 CEST 2015
On Wed, May 20, 2015 at 5:14 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Wed, May 20, 2015 at 5:08 AM, Petr Viktorin <encukou at gmail.com> wrote:
>> On 05/20/2015 01:56 AM, Eric Snow wrote:
>>> Makes sense. This does remind me of something I wanted to ask. Would
>>> it make sense to leverage ModuleSpec.loader_state? If I recall
>>> correctly, we added loader_state with extension modules in mind.
>> I don't think we want to go out of our way to support non-module
>> objects. Module subclasses should cover any needed functionality, and
>> they will support slots.
> Sorry I wasn't clear. ModuleSpec.loader_state isn't related to
> non-module objects or module subclasses. It's a mechanism by which
> finders can pass some loader-specific info to the loader. It could
> also be used to maintain some initial module state separately from the
> module. As I said, I thought we added loader_state with extension
> modules in mind, so I figured I'd ask.
It turns out to be unnecessary.
I will add that if create returns a non-module object, no execution
slots should be specified (i.e. there should only be a Py_mod_create).
That will allow us to change our mind later if this turns out to be a
bad idea, but I doubt it will.
>>> Yuck. Is this something we could fix? Is __module__ not set on all functions?
>> The module object is not stored on classes, so methods dont' have access
>> to it.
> Do classes defined in an extension module not have a __module__
> attribute (holding the module name)?
They do, but that's not good enough:
- Looking up the name in sys.modules is slow.
- Both that and sys.modules are OK to be modified by Python code, so
you can easily get a different module from such a lookup, and using a
different module's state pointer will most likely segfault.
(Maybe this discussion needs a new mail thread?)
>> I want a fix for that to be my next PEP :)
> Cool! It may be good to have an explicit section in this PEP about
> possible follow-up features (e.g. "Out of Scope").
There is a section for follow-up features already (it talks about
possible future slots).
This follow-up didn't make it in -- I think it's too far out of scope,
as it isn't really concerned with loading modules. I think the link in
the section about PyState_FindModule is enough.
> Also, it would be a good idea to have an explicit section in the PEP
> about backward-compatibility. (Pretty sure there wasn't one.) This
> is an important aspect of every PEP and should be clearly
> communicated, even if just to say there is no
> backward-incompatibility. Such a section is also a good place to
> clearly indicate what extension authors need to do to adapt to the new
OK, I can add that. (in the morning; it's 3 AM here so the changes
wouldn't be any good now.)
More information about the Import-SIG