Re: On singleton modules, heap types, and subinterpreters
Petr Viktorin <[email protected]> Tue, 28 Jul 2015 19:48:23 +0200
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CA+=+wqCpr-s6=58BkMiCuhLP6hzZ5Kq0Fq0x63JELjmBLvjRHA@mail.gmail.com> |
On Tue, Jul 28, 2015 at 3:52 PM, Antoine Pitrou <[email protected]> wrote: > On Sun, 26 Jul 2015 12:39:21 +0200 > Petr Viktorin <[email protected]> wrote: >> >> So, what options are there for methods of extension classes to get a >> hold of the module object (or module state)? > > The "obvious" answer is to use the C equivalent of > `sys.modules[__name__]`. It should always do the right thing. However, > it's also quite inefficient and cumbersome to write. We don't have access to globals, so we can't use __name__. We can't use a hardcoded module name either: the fully-qualified name depends on the loading mechanism and/or location of the shared library in the filesystem. (Extension modules usually only hard-code the last part of the module name, without the package prefix.) Another problem is that "sys.modules" can be modified by the user. For Python programs, where you just get a LookupError when something isn't found, looking things up in sys.modules is OK. But here we're retrieving C-level state: when the wrong module isn't found (or we find nothing at all), a segfault is one of the better things that can happen.