Message355104
| Author |
vstinner |
| Recipients |
Michel Desmoulin, ammar2, ncoghlan, r.david.murray, vstinner, xtreak, yselivanov |
| Date |
2019年10月21日.21:29:31 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1571693371.44.0.959429150107.issue20443@roundup.psfhosted.org> |
| In-reply-to |
| Content |
Nick Coghlan:
> I think that's a valid point regarding sys.argv[0] - it's the import system and code introspection that wants(/needs) absolute paths, whereas sys.argv[0] gets used in situations (e.g. usage messages) where we should retain whatever the OS gave us, since that best reflects what the user entered.
Even before this cases, there were different cases where Python does modify sys.argv:
* "python3 -c code ..." command: Python removes code from sys.argv
* runpy.run_module() and runpy.run_path() replace sys.argv[0] with a filename
At the C level, the Py_GetArgcArgv() function provides the "original" argc and argv: before they are modified.
See open issues:
* bpo-14208 (closed): No way to recover original argv with python -m
* bpo-29857: Provide `sys.executable_argv` for host application's command line arguments
* bpo-26388: Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True) |
|