Re: Singleton modules (Re: PEP 489: Redesigning extension module loading)

Petr Viktorin schrieb am 24.04.2015 um 12:19:
> I now think providing singleton
> module support in PEP 489 is, at best, premature.
> If something like it does need to be added in the future, it will need
> better semantics than my current proposal.

I think so, too.


> The third use is as a crutch: the module reference is not passed to
> everything that needs it, so the stuff that needs it reaches out to
> global state.
> A problematic case is a method that needs to raise a module-specific
> exception: _pickle.Unpickler.dumps waits to raise _pickle.Error.
> Unfortunately, while a module's functions have a reference to the module
> (m_self), the classes don't. (And it's rather difficult to store
> arbitrary state on a class object; there's no m_size in
> PyType_FromSpec). So methods pretty much need to peek into global state.

PyCFunctionObject contains a reference to the module, and manually
implemented methods will usually be of that type. But yes, it's a general
problem that it's not passed into the underlying C function.


> I think the right solution would be to give classes a reference to their
> module, as methods have now. And I think this isn't in scope for PEP
> 489. (But it is possibly in scope for the future class-initialization slot.)

Yes, I think the right solution is to extend the type struct, now that it's
created on the heap via PyType_FromSpec() anyway. Then we could add a new
C-API function that reads the module reference for some 'self' object.


> The fourth use is sharing internal state with other modules. The _io
> module is a bit special since it's always available; non-stdlib modules
> should really use capsules for that.

Yes, capsules are the correct mechanism here.

Stefan