You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
All sys attributes (.argv, ...) should exist in embedded environments #76754
Embedded Python interpreters, such as Boost.Python, do not have sys.argv available. (sys itself works fine.) This causes the interpreter to crash with the following exception when you try to access argv:
AttributeError: 'module' object has no attribute 'argv'
I'm not sure how closely related this is to bpo-15577 or PEP-432. A simple workaround is to manually assign a list with an empty string to argv, as suggested by googleapis/oauth2client#642. However, the documentation for the sys module makes no mention of this special case for argv, and the line at the top that says "It is always available" can easily be interpreted to mean that *all* of sys's attributes will always be available. I suggest adding the following to the documentation for sys.argv:
========
Since argv contains the list of command line arguments passed to the Python interpreter, argv is not available within embedded interpreters, and scripts that run in embedded environments will raise an AttributeError when they attempt to access argv. As a workaround, assign a list with an empty string manually:
import sys
if not hasattr(sys, 'argv'):
sys.argv = ['']
A better question might be: is there something in the embedding framework that should initialize argv to the empty list? embedding framework here could have two meanings: either the third party code, or the code that we provide for supporting embedding.
pgacv2 commented on Jan 17, 2018
pgacv2mannequin
MannequinAuthor
More actions
My first inclination would be no. An argv value of [''] means "zero command-line arguments" (not even a filename), which implies the following as far as I know:
Python was called as an executable rather than a library, because you can't pass command-line arguments to a library
No arguments were passed to the executable
You are running from inside the REPL
All three are false in an embedded context.
A not-much-better-but-maybe-worth-considering question might also be: should scripts be able to tell whether they are being run from an embedded interpreter? If so, do they have any other way of doing so if an initialization is forced for argv?
pgacv2 commented on Jan 17, 2018
pgacv2mannequin
MannequinAuthor
More actions
My comment above uses "code that we provide for supporting embedding," not "third party code," as the definition of embedded.
There are actually 3 attributes that may be absent when CPython itself isn't managing the C level entry point: sys.argv, sys.warnoptions, and sys._xoptions.
I'd be more inclined to make the implementation match the docs though, and have these all be empty lists in the not-configured case, rather than absent entirely. (Accessing sys.argv[0] would still be an error in that situation, just an IndexError instead of an AttributeError)
Pedro: David and Nick are proposing initializing sys.argv to [] rather than [''] for embedded interpreters. This would say 'running embedded'. The .argv entry would need an additional sentence.
I like Nick's proposal, except that _xoptions should be {}. Documenting absence should only be a fallback is there is no sensible default.
changed the title [-]sys.argv documentation should include caveat for embedded environments[/-][+]All sys attributes (.argv, ...) should exist in embedded environments[/+]on Jan 19, 2018
pgacv2 commented on Jan 20, 2018
pgacv2mannequin
MannequinAuthor
More actions
I agree that an empty list, instead of a list with an empty string, makes more sense. Leaving _xoptions as {} would be the same as when it runs non-embedded without any -X arguments, but I guess there's no way of making {} any more empty.
Activity
pgacv2 commentedon Jan 16, 2018
Embedded Python interpreters, such as Boost.Python, do not have sys.argv available. (sys itself works fine.) This causes the interpreter to crash with the following exception when you try to access argv:
I'm not sure how closely related this is to bpo-15577 or PEP-432. A simple workaround is to manually assign a list with an empty string to argv, as suggested by googleapis/oauth2client#642. However, the documentation for the sys module makes no mention of this special case for argv, and the line at the top that says "It is always available" can easily be interpreted to mean that *all* of sys's attributes will always be available. I suggest adding the following to the documentation for sys.argv:
========
Since
argvcontains the list of command line arguments passed to the Python interpreter,argvis not available within embedded interpreters, and scripts that run in embedded environments will raise anAttributeErrorwhen they attempt to accessargv. As a workaround, assign a list with an empty string manually:bitdancer commentedon Jan 16, 2018
A better question might be: is there something in the embedding framework that should initialize argv to the empty list? embedding framework here could have two meanings: either the third party code, or the code that we provide for supporting embedding.
pgacv2 commentedon Jan 17, 2018
My first inclination would be no. An argv value of [''] means "zero command-line arguments" (not even a filename), which implies the following as far as I know:
All three are false in an embedded context.
A not-much-better-but-maybe-worth-considering question might also be: should scripts be able to tell whether they are being run from an embedded interpreter? If so, do they have any other way of doing so if an initialization is forced for argv?
pgacv2 commentedon Jan 17, 2018
My comment above uses "code that we provide for supporting embedding," not "third party code," as the definition of embedded.
ncoghlan commentedon Jan 17, 2018
There are actually 3 attributes that may be absent when CPython itself isn't managing the C level entry point: sys.argv, sys.warnoptions, and sys._xoptions.
I'd be more inclined to make the implementation match the docs though, and have these all be empty lists in the not-configured case, rather than absent entirely. (Accessing sys.argv[0] would still be an error in that situation, just an IndexError instead of an AttributeError)
terryjreedy commentedon Jan 19, 2018
Pedro: David and Nick are proposing initializing sys.argv to [] rather than [''] for embedded interpreters. This would say 'running embedded'. The .argv entry would need an additional sentence.
I like Nick's proposal, except that _xoptions should be {}. Documenting absence should only be a fallback is there is no sensible default.
[-]sys.argv documentation should include caveat for embedded environments[/-][+]All sys attributes (.argv, ...) should exist in embedded environments[/+]pgacv2 commentedon Jan 20, 2018
I agree that an empty list, instead of a list with an empty string, makes more sense. Leaving _xoptions as {} would be the same as when it runs non-embedded without any -X arguments, but I guess there's no way of making {} any more empty.
terryjreedy commentedon Jan 20, 2018
For detecting 'embedded', it is enough that only one documented attribute value be unique to embedded situations.
vstinner commentedon May 13, 2019
In Python 3.8, sys.argv is now always created. It's initialized to sys.argv = [""] if (argc, argv) are not set in _PyCoreConfig.
So PR 12463 looks useless to me, except if someone wants to change the behavior.
vstinner commentedon May 13, 2019
See also the PEP-587.
vstinner commentedon Jun 2, 2019
The issue has been fixed in Python 3.8. See PEP-587 and http://docs.python.org/dev/c-api/init_config.html for the larger scope.
For Python 3.7, the fix is trivial: don't add the following 2 lines in your application:
Python 3.7 Release Manager, Ned Deily, was opposed to change the behavior in a minor release:
#13553 (comment)