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

[Nick Coghlan]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130901/d26b0f00/attachment.html>