[Python-3000] Draft PEP: Module Initialization and finalization

["Martin v. Löwis"]

Thomas Wouters wrote:
> I wonder if standardization of the struct layout of 'struct state', and
> the naming scheme of 'struct state', 'module_slot' and 'STATE' would be
> desireable. The state and module_slot structs would be c-file-static, so
> naming conflicts shouldn't exist, and it would improve readability the
> way Py_VISIT does (IMHO.) 

I was thinking about that: a fixed naming should work. Not sure what
you mean by a standardized layout: you certainly want to put arbitrary
data in the module state (and, in particular, not a Python dictionary -
people could already lookup exception objects in the module's
dictionary, but they prefer "real pointers").

> In fact, maybe the struct state should just be
> the module object, as a C-subclass of the module type?

That would also work.

> In fact... perhaps module functions should then get the module object as
> the first argument (currently unused but always defined)?

That wouldn't work: the first argument currently *is* used, atleast
if you pass a non-NULL value for self to Py_InitModule4. Of course,
we could drop that in Py3k, and declare that you always get the module
object.

However, that still wouldn't fully work, since you might need access
to module objects in a method of a type you implemented, where self
is the object. So I think you need some way to go through the current
interpreter.

> I think, for Py3K, we should bite the bullet and not check init<module>.
> Extension writers will have to update their init-functions anyway,
> because PyImport_InitModule* all changes (I hope!) While we're at it,
> should generate the init<module> name (and maybe prototype) by macro
> instead of relying on the user to get the naming right?

That would also work. But, if we also have finalizers, we already
need two macros to generate the function name.

> It'd allow
> easier changing of the naming and such in the future, but I don't know
> if that outweighs the discomfort of hiding function prototypes. Probably
> not.

Right.

Martin