[Python-Dev] Pre-PEP: Redesigning extension modules

[Antoine Pitrou]

Le Sun, 1 Sep 2013 02:19:48 +1000,
Nick Coghlan <ncoghlan at gmail.com> a écrit :
> On 1 Sep 2013 00:10, "Stefan Behnel" <stefan_ml at behnel.de> wrote:
> >
> > *bump*
> >
> > Does this sound like a viable solution?
> 
> This isn't likely to progress until we have Eric's PEP 451 to a point
> where it's ready for python-dev discussion and pronouncement.
> 
> However, the revised loader API is being designed to allow for the
> loader returning arbitrary objects, so something along these lines
> should work. There will likely be some adjustments to the API
> signature to allow extension modules to optionally support reloading
> if they so desire.

I think the biggest challenge here is to propose an API that's simple
and easy to use (i.e. that doesn't make extension module writing more
complicated than it currently is).

The basic concept of putting custom module objects in sys.modules is
sound, IMHO.

As for "extension module as a wrapper", though, it shounds like the
kind of complication I would personally prefer to stay away from. Also,
it would make extension modules less like Python modules, rather than
more.

Regards

Antoine.



> 
> Cheers,
> Nick.
> 
> >
> > Stefan
> >
> >
> > Stefan Behnel, 25.08.2013 14:36:
> > > Hi,
> > >
> > > thanks for bringing this up. It clearly shows that there is more
> > > to this problem than I initially thought.
> > >
> > > Let me just add one idea that your post gave me.
> > >
> > > PJ Eby, 25.08.2013 06:12:
> > >> My "Importing" package offers lazy imports by creating module
> > >> objects in sys.modules that are a subtype of ModuleType, and use
> > >> a __getattribute__ hook so that trying to use them fires off a
> > >> reload() of the module.
> > >
> > > I wonder if this wouldn't be an approach to fix the reloading
> > > problem in general. What if extension module loading, at least
> > > with the new scheme, didn't return the module object itself and
> > > put it into sys.modules but created a wrapper that redirects its
> > > __getattr__ and __setattr__ to the actual module object? That
> > > would have a tiny performance impact on attribute access, but I'd
> > > expect that to be negligible given that the
> usual
> > > reason for the extension module to exist is that it does
> > > non-trivial
> stuff
> > > in whatever its API provides. Reloading could then really create a
> > > completely new module object and replace the reference inside of
> > > the
> wrapper.
> > >
> > > That way, code that currently uses "from extmodule import xyz"
> > > would continue to see the original version of the module as of
> > > the time of its import, and code that just did "import extmodule"
> > > and then used
> attribute
> > > access at need would always see the current content of the module
> > > as it
> was
> > > last loaded. I think that, together with keeping module global
> > > state in
> the
> > > module object itself, would nicely fix both cases.
> > >
> > > Stefan
> >
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>