The following short program work in python 2.5, but does die with a SystemError in python2.6: ~/ cat t.py #! /usr/bin/env python res = dict(__package__='foo') exec "from os import path" in res ~/ python2.5 t.py ~/ python2.6 t.py Traceback (most recent call last): File "t.py", line 4, in exec "from os import path" in res File "", line 1, in SystemError: Parent module 'foo' not loaded I think this has been introduced with svn revision 42649 (http://hgpy.de/py/trunk/rev/54c72e1678d68ebbf274) Part of the diff reads: modules = PyImport_GetModuleDict(); parent = PyDict_GetItemString(modules, buf); if (parent == NULL) - parent = Py_None; + PyErr_Format(PyExc_SystemError, + "Parent module '%.200s' not loaded", buf); return parent; /* We expect, but can't guarantee, if parent != None, that:
Hmm, setting an invalid value for __package__ will definitely break relative imports (see PEP 361), but it probably shouldn't be breaking absolute imports.
One idea would be to change the import code to only produce a warning for a missing __package__ entry instead of a SystemError (reserving the SystemError for cases where the package name is derived from __name__ rather than being retrieved from the __package__ attribute).
Bumped priority - an existing module shouldn't crash in 2.6 just because we started using __package__ as part of the import mechanism and that module happens to already set an attribute by that name.
Fixed in r64915. The end result is that the import system now only emits a RuntimeWarning instead of raising SystemError if it can't find the parent module when attempting to perform an absolute import (regardless of whether the parent module name was derived from __package__ or from __name__). Explicit relative imports will still fail if __package__ is set incorrectly and setting __package__ to a non-string value will still result in a ValueError.
