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: Way working directory is added to sys.path differs between using -c or -m
Type: behavior Stage:
Components: Documentation, Interpreter Core Versions: Python 3.9, Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, plammens, vstinner
Priority: normal Keywords:

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) * (Python committer) 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:38adminsetgithub: 86649
2020-11-27 20:15:57plammenssetmessages: + msg381963
2020-11-27 19:33:20vstinnersetnosy: + vstinner
messages: + msg381960
2020-11-27 10:59:48plammenscreate