Re: PEP 489: Multi-phase extension module initialization; version 5

On Wed, May 20, 2015 at 5:14 PM, Eric Snow <[email protected]> wrote:
> On Wed, May 20, 2015 at 5:08 AM, Petr Viktorin <[email protected]> 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.

>   [snip]
>>> 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
> feature.

OK, I can add that. (in the morning; it's 3 AM here so the changes
wouldn't be any good now.)