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

Nick Coghlan ncoghlan at gmail.com
Sat Aug 31 18:19:48 CEST 2013

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.


> 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
> > reason for the extension module to exist is that it does non-trivial
> > in whatever its API provides. Reloading could then really create a
> > completely new module object and replace the reference inside of the
> >
> > 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
> > access at need would always see the current content of the module as it
> > last loaded. I think that, together with keeping module global state in
> > 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:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130901/d26b0f00/attachment.html>

More information about the Python-Dev mailing list