than a Python module (e.g. "__init__.py"): don't close the file twice.
PyFile_FromFile() does also close the file if PyString_FromString() failed. It
did already close the file on fill_file_fields() error (e.g. if the file is a
directory).
find_module() now raises a RuntimeError, instead of ImportError, on an error on
sys.path or sys.meta_path because load_package() and import_submodule() returns
None and clear the exception if a ImportError occurred.
(e.g. from .os import sep) and it failed, import would still try the implicit
relative import semantics of an absolute import (from os import sep). That's
not right, so when level is negative, only do explicit relative import
semantics.
Fixes issue #7902. Thanks to Meador Inge for the patch.
(SIGINT). If an error occurs while importing the site module, the error is
printed and Python exits. Initialize the GIL before importing the site
module.
acquiring the import lock around fork() calls. This prevents other threads
from having that lock while the fork happens, and is the recommended way of
dealing with such issues. There are two other locks we care about, the GIL
and the Thread Local Storage lock. The GIL is obviously held when calling
Python functions like os.fork(), and the TLS lock is explicitly reallocated
instead, while also deleting now-orphaned TLS data.
This only fixes calls to os.fork(), not extension modules or embedding
programs calling C's fork() directly. Solving that requires a new set of API
functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
warning explaining the problem to the documentation in the mean time.
This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
getting the import lock reallocated, seemingly to avoid this very same
problem. This is not the right approach, because the import lock is a
re-entrant one, and reallocating would do the wrong thing when forking while
holding the import lock.
Will backport to 2.6, minus the tiny AIX behaviour change.
