STINNER Victor <vstin...@python.org> added the comment:
Ronald Oussoren: > A list of stdlib modules/extensions is IMHO problematic for maintenance, esp. > if you consider that not all modules/extensions are installed on all systems > (both because dependencies aren't present and because packagers have decided > to unbundle parts of the stdlib). My PR 24238 adds a list of module names (tuple of str): sys.module_names. It includes modules which are not available on the platform. For example, "winsound" is listed on Linux but not available, and "tkinter" is listed even if the extension could not be built (missing dependency). I tried to make it clear in the sys.module_names documentation (see my PR). Making the list conditional depending if the module is built or not is causing different issues. For example, for the "isort" (sort and group imports) use case, you want to know on Linux if "import winsound" is a stdlib import or a third party import (same for Linux-only modules on Windows). Moreover, there is a practical issue: extension modules are only built by setup.py *after* the sys module is built. I don't want to rebuild the sys module if building an extension failed. Even if a module is available (listed in sys.module_names and the file is present on disk), it doesn't mean that "it works". For example, "import multiprocessing" fails if there is no working lock implementation. Other modules have similar issues. > Wouldn't it be sufficient to somehow mark the stdlib entries on sys.path? > Although that might give misleading answers with tools like > pyinstaller/py2exe/py2app that package an application and its dependencies > into a single zipfile. Having to actually import modules to check if it's a stdlib module or not is not convenient. Many stdlib modules have side effects on import. For example, "import antigravity" opens a web browser. An import can open files, spawn threads, run programs, etc. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42955> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
