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.

classification
Title: implementations of the deprecated load_module import loader API, as prescribed by the documentation, are not thread safe
Type: behavior Stage:
Components: Documentation Versions: Python 3.10, Python 3.9, Python 3.8, Python 3.7, Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, kale-smoothie
Priority: normal Keywords:

Created on 2021-03-29 16:53 by kale-smoothie, last changed 2022-04-11 14:59 by admin.

Files
File name Uploaded Description Edit
thread_unsafe_import.py kale-smoothie, 2021-03-29 16:52 set env var PICK_API=N with N in {0,1} to demonstrate thread unsafe import and N=2 for expected behaviour
Messages (1)
msg389713 - (view) Author: kale-smoothie (kale-smoothie) * Date: 2021-03-29 16:52
Unless I've misread or misunderstood, the documentation at https://docs.python.org/3/reference/import.html#loaders for the deprecated `load_module` method doesn't indicate any requirements or caveats for thread safe importing. As it stands, I think it is not thread-safe, since the module is not protected against concurrent imports by the internal implementation marker `__spec__._initializing = True`.

Additionally, the deprecated function decorator, `importlib.util.module_for_loader` seems to implement the marker incorrectly (sets `__initializing__` directly on the module).

I think this behaviour should either be documented as a major caveat, or internal details exposed to allow thread-safe implementations, or the old API removed entirely.
History
Date User Action Args
2022-04-11 14:59:43adminsetgithub: 87824
2021-03-29 16:53:01kale-smoothiecreate