New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide sys.executable_argv
for host application's command line arguments
#74043
Comments
bpo-14208 was ultimately resolved through an import system specific solution, with PEP-451 making the module name passed to However, there are other situations where it may be useful to offer an implementation-dependent attribute in the In the case of CPython, where |
As bytes? |
For CPython, I was thinking of having it be "whatever gets passed to Py_Main", and that accepts wchar_t in Py3 [1], so on *Nix systems, the command line has already been decoded with [2] by the time it runs. [1] https://docs.python.org/3/c-api/veryhigh.html#c.Py_Main In the case of Windows, the wchar_t array is received straight from the OS as UTF-16-LE. |
Why is the name flagged as a private implementation detail? I.e. a single leading underscore. I'd be reluctant to rely on this in production code, given how strong the _private convention is. Suggest just |
No, text please. Text is just more convenient in Python, and it's trivial to retrieve original bytes: raw_args_bytes = [os.fsencode(arg) for arg in sys._raw_args] |
On Mar 21, 2017, at 11:47 AM, STINNER Victor wrote:
Well, "raw args" implies minimal or no processing, so bytes would make the |
Ok, so call it "original", sys.orig_arv, in that case ;-) |
There is already an existing public C API get retrieve original program arguments *as text*: /* Make the *original* argc/argv available to other modules. void
Py_GetArgcArgv(int *argc, wchar_t ***argv)
{
*argc = orig_argc;
*argv = orig_argv;
} Are you talking about exposing these arguments at the Python level? |
@steven This is an implementation detail in the same sense that sys._getframe() is: it's not something that's actually going to make sense in all contexts. For example, if Py_Main() is never called (for CPython), it would still be None, and other implementations may not define it at all. And even when it's set for CPython, the exact details of what it contains are going to be at least somewhat platform dependent. @barry On Windows we define One option would be to use a longer name like @victor It wouldn't be exactly the same as Py_GetArgcArgv, as I'd propose making a pristine copy *before* Py_Main() mutates anything - we do some in-place editing of entries while figuring out what "sys.argv[0]" should look like at the Python level. |
What is the content of sys.argv in that case? Can't we use the same value for sys._raw_argv? |
If the embedding application doesn't call PySys_SetArgv or PySys_SetArgvEx, then there is no For the reference CLI, the relevant call happens in Py_Main() after all the interpreter level arguments have been processed. |
Ok, so just don't define sys._raw_argv in that case. But it doesn't seem enough to me to justify to make the attribute private. https://docs.python.org/dev/library/sys.html#sys.getallocatedblocks can be seen as an implementation detail.The method name has no underscore prefix, but a simple fallback: return 0 if the feature is is not implemented. |
OK, I've changed the proposed attribute name to be As part of documenting this, both it and the |
sys._raw_argv
for host application's command line argumentssys.executable_argv
for host application's command line arguments
I mark this issue as a duplicate of bpo-23427 which has patch and is older. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: