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.

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:

1. Python was called as an executable rather than a library, because you can't pass command-line arguments to a library
2. No arguments were passed to the executable
3. 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?

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.

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.

For detecting 'embedded', it is enough that only one documented attribute value be unique to embedded situations.

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.

See also the PEP-587.

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:

if not hasattr(sys, 'argv'):
    sys.argv = ['']

Python 3.7 Release Manager, Ned Deily, was opposed to change the behavior in a minor release:
#13553 (comment)