[Import-SIG] PEP 451 (ModuleSpec) round 3

[Nick Coghlan]

On 2 September 2013 18:32, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le Sun, 1 Sep 2013 22:47:56 +1000,
> Nick Coghlan <ncoghlan at gmail.com> a écrit :
>> > The life-cycle of module state, both internal and external, is
>> > pretty congruent with objects in Python:
>> >
>> > 1. create
>> > 2. init
>> > 3. modify
>> > 4. destroy
>>
>> I'd tweak this slightly, and say that modules are more congruent with
>> *class namespaces* than they are with ordinary objects (which is why I
>> chose "prepare" as a suggested alternative to "create"). The main
>> difference is that we don't support reinitialising a class namespace
>> in place, while we do support doing so for modules.
>
> Given that modules are already instances of the module type, and given
> most Python users are much more familiar with the semantics of object
> namespaces, rather than those of class namespaces, I'd strongly rather
> have modules stay instance-alike, rather than type-alike.

They're not *that* much like either at runtime, since the descriptor
machinery is deliberately turned off for module instances.

The data model during execution is the same as that of a class body,
though. It's just that module level corresponds to exec when globals
and locals refer to the same namespace, while class bodies use the
module globals and their own locals. That's the part that makes me see
the parallel with prepare/exec for type instances as more significant
than that with new/init for normal class instances.

> (haven't read the latest PEP update, though)
>
>> This
>> includes exposing already bound instance methods of a hidden state
>> object rather than ordinary functions for any top level callables,
>
> Er... There may (or even will) be compatibility issues with that. Such
> as pickling of top level functions, or the various discrepancies of
> bound methods vs. plain functions. Or, of course, all the changes in
> introspection results that might disrupt existing code (think
> the various `inspect` functions).
>
> I think it would be much safer to have top level functions remain
> plain functions, and take the module object as first argument as they
> already do (the "PyObject *self"). And it would help extension modules
> be more like normal Python modules.

Yeah, I made that suggestion when I was confused between which of
PyModule_GetState and PyState_GetModule caused problems. Since it's
only the latter, there's no need to muck about with exposing bound
methods of objects with hidden state - we already have that by calling
"PyModule_GetState" on the module parameter.

Cheers,
Nick.

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