This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author petr.viktorin
Recipients brett.cannon, christoph.wiedemann, cschramm, eric.snow, ncoghlan, petr.viktorin, scoder
Date 2018-08-02.10:53:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1533207185.58.0.56676864532.issue34309@psf.upfronthosting.co.za>
In-reply-to
Content
PEP 489 (Multi-phase extension module initialization) makes it possible/easy to unload/reimport extension modules, in the sense of destroying/recreating the module object. The problem is that the modules needs to opt-in to supporting this, which is not always easy (e.g. the module needs to not use C globals, or use them carefully), and sometimes it's still nearly impossible (see the in-progress PEP 573).

Unloading the actual shared library is another matter, though. That's not currently planned. There's no good way to ensure that there no remaining objects that could reference the shared library's code.
Instead, your best bet is probably to name the new .so/DLL differently, and load an extra copy. (PEP 489 makes it possible to make the .so/DLL contain a module with a different name.) If you do go this way, I'd welcome feedback.
History
Date User Action Args
2018-08-02 10:53:05petr.viktorinsetrecipients: + petr.viktorin, brett.cannon, ncoghlan, scoder, eric.snow, cschramm, christoph.wiedemann
2018-08-02 10:53:05petr.viktorinsetmessageid: <1533207185.58.0.56676864532.issue34309@psf.upfronthosting.co.za>
2018-08-02 10:53:05petr.viktorinlinkissue34309 messages
2018-08-02 10:53:05petr.viktorincreate