[issue42483] Way working directory is added to sys.path differs between using -c or -m

2020-11-27 Thread Paolo Lammens

Paolo Lammens  added the comment:

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  wrote:

>
> STINNER Victor  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 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42483] Way working directory is added to sys.path differs between using -c or -m

2020-11-27 Thread STINNER Victor


STINNER Victor  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42483] Way working directory is added to sys.path differs between using -c or -m

2020-11-27 Thread Paolo Lammens

New submission from Paolo Lammens :

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 \**
> 
>[...]
> 
>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 \**
> 
>[...]
> 
>If this option is given, the first element of `sys.argv` will be
>thefull 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 
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.

--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 381942
nosy: docs@python, plammens
priority: normal
severity: normal
status: open
title: Way working directory is added to sys.path differs between using -c or -m
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com