Known limitations of the current implementation:
- documentation changes are incomplete
- there's a reference leak I haven't tracked down yet
The leak is most visible by running:
./python -m test -R3:3 test_importlib
However, you can also see it by running:
./python -X showrefcount
Importing the array or _testmultiphase modules, and
then deleting them from both sys.modules and the local
namespace shows significant increases in the total
number of active references each cycle. By contrast,
with _testcapi (which continues to use single-phase
initialisation) the global refcounts stabilise after
a couple of cycles.
importlib._bootstrap is now frozen into Python/importlib.h and stored
as _frozen_importlib in sys.modules. Py_Initialize() loads the frozen
code along with sys and imp and then uses _frozen_importlib._install()
to set builtins.__import__() w/ _frozen_importlib.__import__().
The name must be encodable to ASCII because dynamic module must have a function
called "PyInit_NAME", they are written in C, and the C language doesn't accept
non-ASCII identifiers.
- is_builtin(), init_builtin(), load_builtin() and other builtin related
functions use Unicode strings, instead of byte strings
- Rename _PyImport_FixupExtensionUnicode() to _PyImport_FixupExtensionObject()
- Rename _PyImport_FindExtensionUnicode() to _PyImport_FindExtensionObject()
* Rename _PyImport_FindExtension() to _PyImport_FindExtensionUnicode():
the filename becomes a Unicode object instead of byte string
* Rename _PyImport_FixupExtension() to _PyImport_FixupExtensionUnicode():
the filename becomes a Unicode object instead of byte string
Changes to make __file__ a proper Unicode object, using the default
filesystem encoding.
This is a bit tricky because the default filesystem encoding isn't
set by the time we import the first modules; at that point we fudge
things a bit. This is okay since __file__ isn't really used much
except for error reporting.
Tested on OSX and Linux only so far.
When an extension imports another extension in its
initXXX() function, the variable _Py_PackageContext is
prematurely reset to NULL. If the outer extension then
calls Py_InitModule(), the extension is installed in
sys.modules without its package name. The
manifestation of this bug is a "SystemError:
_PyImport_FixupExtension: module <package>.<extension>
not loaded".
To fix this, importdl.c just needs to retain the old
value of _Py_PackageContext and restore it after the
initXXX() method is called. The attached patch does this.
This patch applies to Python 2.1.1 and the current CVS.
