Re: PEP 451 (ModuleSpec) round 3

Le Sun, 1 Sep 2013 22:47:56 +1000,
Nick Coghlan <[email protected]> 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.

(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.

Regards

Antoine.


_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig