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.

Author maggyero
Recipients maggyero, ncoghlan
Date 2020-09-19.15:43:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1600530238.56.0.932749272178.issue41814@roundup.psfhosted.org>
In-reply-to
Content
Nicholas, I have noticed that `runpy.run_path` alters `sys.path` as expected for a file_path argument which is a valid `sys.path` entry (typically a directory or zip file). That is to say it adds the file_path argument to the beginning of `sys.path`, like `python <valid sys.path entry>`.

However, I have also noticed that `runpy.run_path` does not alter `sys.path` as expected for a file_path argument which is a Python source or bytecode file path. That is to say it does not add the *parent path* of the file_path argument to the beginning of `sys.path`, contrary to `python <source or bytecode file path>`.

Likewise, I have also noticed that `runpy.run_module` (with the alter_sys argument set to `True` of course) does not alter `sys.path` as expected. That is to say it does not add the path of the *current directory* to the beginning of `sys.path`, contrary to `python -m <module>`.

Only the first of the three previous `sys.path` manipulations is documented in https://docs.python.org/3/library/runpy.html though, so the `runpy` implementation is at least compliant with its specification. So is the mismatch between the manipulation of `sys.path` by `runpy` and by the Python command-line interface a specification bug or is it the intended behaviour?
History
Date User Action Args
2020-09-19 15:43:58maggyerosetrecipients: + maggyero, ncoghlan
2020-09-19 15:43:58maggyerosetmessageid: <1600530238.56.0.932749272178.issue41814@roundup.psfhosted.org>
2020-09-19 15:43:58maggyerolinkissue41814 messages
2020-09-19 15:43:58maggyerocreate