Issue42483
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.
Created on 2020-11-27 10:59 by plammens, last changed 2022-04-11 14:59 by admin.
Messages (3) | |||
---|---|---|---|
msg381942 - (view) | Author: Paolo Lammens (plammens) * | Date: 2020-11-27 10:59 | |
Tested on: - Python 3.8.6 for Windows 10 64 bit - Python 3.9.0 for Windows 10 64 bit - Python 3.8.6 for Ubuntu 20.04 - Python 3.9.0 for Ubuntu 20.04 Originally asked here: https://stackoverflow.com/q/65024647/6117426 --------------------------------------------------------------------- If you launch a Python process either as a single command from the command line (with the `-c` flag) or by specifying a module path (with the `-m` flag), the working directory is prepended to `sys.path`. From the [docs](https://docs.python.org/3/using/cmdline.html#cmdoption-c) (emphases mine): > - **-c \<command\>** > > [...] > > If this option is given, the first element of `sys.argv` will be > `"-c"` and **the current directory will be added to the start of > `sys.path`** (allowing modules in that directory to be imported as top level > modules). > > [...] > > - **-m \<module-name\>** > > [...] > > If this option is given, the first element of `sys.argv` will be > the full path to the module file (while the module file is being > located, the first element will be set to `"-m"`). As with the > `-c` option, **the current directory will be added to the start of > `sys.path`**. > > [...] But it seems the way this is done is different for each option: ```none $ python -c "import sys; print sys.path" ['', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/plammens/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages'] $ python -m script # script.py does the same as the command above ['/mnt/c/Users/Paolo/Desktop/Code Sandbox/Python/clean', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/plammens/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages'] ``` Notice how the first option uses an empty string to denote the current working directory while the second explicitly adds the path to the directory I ran the command in. The empty string is always interpreted dynamically to denote the current working directory during execution, as per the [docs on the import system](https://docs.python.org/3/reference/import.html): > The current working directory – denoted by an empty string – is > handled slightly differently from other entries on `sys.path`. First, if > the current working directory is found to not exist, no value is > stored in `sys.path_importer_cache`. Second, **the value for the current > working directory is looked up fresh for each module lookup**. Third, > the path used for `sys.path_importer_cache` and returned by > `importlib.machinery.PathFinder.find_spec()` will be the actual current > working directory and not the empty string. So this means that the `-c` version will always use the current working directory of the Python process, not the directory that it was originally launched in. Indeed, we can make an example to show this. Consider the following file tree, ```none . ├── script.py └── secret-folder └── findme.py ``` with `findme.py` just containing the one statement `print("you found me!")`. If we run the following ```python import os os.chdir('secret-folder') import findme ``` both as a command (`-c`) and as a script (in `script.py`), we get: ```none $ python -c "import os; os.chdir('secret-folder'); import findme" you found me! $ python -m script Traceback (most recent call last): File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.8/runpy.py", line 87, in _run_code exec(code, run_globals) File "/.../script.py", line 5, in <module> import findme ModuleNotFoundError: No module named 'findme' ``` This is because `-m` is using the "hardcoded" working directory while `-c` is using the "dynamically interpreted" current directory. By how it's phrased in the documentation for `-c` and `-m` though, one would think these two should behave identically. Is this intended? If so, it isn't documented. |
|||
msg381960 - (view) | Author: STINNER Victor (vstinner) * | Date: 2020-11-27 19:33 | |
See https://discuss.python.org/t/python-flag-envvar-not-to-put-current-directory-to-sys-path-but-dont-ignore-pythonpath/4235 discussion. |
|||
msg381963 - (view) | Author: Paolo Lammens (plammens) * | Date: 2020-11-27 20:15 | |
Hmm I think that’s unrelated; it’s a discussion about whether to add or not the working directory at all. Here the issue is that the way it *is* added differs between -c and -m (which isn’t documented). In both cases it is added (I’m not discussing that) but with -c it is added as an empty string while with -m it’s expanded to the full path beforehand, which results in different behaviour. On Fri, 27 Nov 2020 at 20:33, STINNER Victor <report@bugs.python.org> wrote: > > STINNER Victor <vstinner@python.org> added the comment: > > See > https://discuss.python.org/t/python-flag-envvar-not-to-put-current-directory-to-sys-path-but-dont-ignore-pythonpath/4235 > discussion. > > ---------- > nosy: +vstinner > > _______________________________________ > Python tracker <report@bugs.python.org> > <https://bugs.python.org/issue42483> > _______________________________________ > |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:59:38 | admin | set | github: 86649 |
2020-11-27 20:15:57 | plammens | set | messages: + msg381963 |
2020-11-27 19:33:20 | vstinner | set | nosy:
+ vstinner messages: + msg381960 |
2020-11-27 10:59:48 | plammens | create |