Ah, I see that I didn't explain something well. The issue has two sides: one side is a fix security vulnerability, the second side is more about Python *usability*.
The Python usability issue is that running "math.py" overrides the Python stdlib module called "math". "math.py" is just an example, Python 3.11 contains has 305 modules: a name conflict is likely, especially by users learning Python fall into this trap (create a file called "random.py" to play with the "random" module). The issue so common that IPython added a "launcher" to work around this issue, to remove sys.path[0]: https://github.com/ipython/ipykernel/commit/3f7a03d356eee3500261acf9eec6bad2196c2097 Another example is the pytest project: running "pytest [...]" is different than "python -m pytest [...]". The second command adds the current working directory which can change the test behavior. It's a documented issue: https://docs.pytest.org/en/latest/how-to/usage.html#calling-pytest-through-python-m-pytest For the pytest use case, you still want to add the user site directory to sys.path and you still want to accept PYTHON environment variables like PYTHONWARNINGS. The only thing that you don't want is to add the current working directory to sys.path. Read also this discussion by Miro Hrončok about this usability issue in Fedora: https://discuss.python.org/t/python-flag-envvar-to-not-put-current-directory-on-sys-path-but-dont-ignore-pythonpath/4235 Victor On Wed, Apr 27, 2022 at 5:57 PM Victor Stinner <vstin...@python.org> wrote: > > The use case for -P still uses environment variables like > PYTHONWARNINGS or PYTHONUTF8. That's why -I (isolated) cannot be used. > > If there is an use case for a ._pth file importing the site module, > maybe a different option can be added, no? Adding -P doesn't prevent > that. But it seems like use cases are different enough to justify two > options, no? > > Victor > > > On Tue, Apr 26, 2022 at 11:52 PM Victor Stinner <vstin...@python.org> wrote: > > The only purpose of proposed -P option is to "not add sys.path[0]". > > There are use cases which only need that. > > > > Victor > > > > On Tue, Apr 26, 2022 at 8:37 PM Steve Dower <steve.do...@python.org> wrote: > > > > > > On 4/26/2022 10:46 AM, Victor Stinner wrote: > > > > I propose adding a -P option to Python command line interface to "not > > > > add sys.path[0]": > > > > https://github.com/python/cpython/pull/31542 > > > > > > > > See the documentation in the PR for the exact behavior of this option. > > > > I prefer to add an environment variable, only pass the option > > > > explicitly on the command line. > > > > > > Another viable option might be to add an option to imply "import site", > > > which would work together with -I to: > > > * ignore environment variables (-E/-I) > > > * omit implicit CWD imports (-I) > > > * still process .pth files (-?) > > > * still include site-packages and user site-packages in sys.path (-?) > > > > > > It seems likely that the proposed -P would almost always be used with > > > -E, since if you can't control CWD then you presumably can't control > > > environment variables either. > > > > > > The existing ._pth functionality starts by implying -I, and allows > > > "import site" in the file to explicitly include site. A command-line > > > option matching this behaviour would be consistent. There's also already > > > configuration in our structures for import site, so there'd be no need > > > to add new fields to public APIs for the option. > > > > > > The biggest issue I see is that the obvious command line options for > > > "import site" are already used to imply "do not import site". But then, > > > -P isn't obvious either. Maybe an -X option would suffice? > > > > > > Cheers, > > > Steve > > > > > > > > > -- > > Night gathers, and now my watch begins. It shall not end until my death. > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A65CZFDNPXGBMENQD56VHF2QXDS3ENIC/ Code of Conduct: http://python.org/psf/codeofconduct/
