$ python3.4 -S -m site
sys.path = [
    '',
    '/home/antoine/opt/lib/python34.zip',
    '/home/antoine/opt/lib/python3.4/',
    '/home/antoine/opt/lib/python3.4/plat-linux',
    '/home/antoine/opt/lib/python3.4/lib-dynload',
]
Traceback (most recent call last):
  File "/home/antoine/opt/lib/python3.4/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/antoine/opt/lib/python3.4/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/antoine/opt/lib/python3.4/site.py", line 640, in <module>
    _script()
  File "/home/antoine/opt/lib/python3.4/site.py", line 612, in _script
    "exists" if os.path.isdir(USER_BASE) else "doesn't exist"))
  File "/home/antoine/opt/lib/python3.4/genericpath.py", line 42, in isdir
    st = os.stat(s)
TypeError: stat: can't specify None for path argument

Hmm, it works in 3.2, so I suspect that's a symptom of the code change that skipped the side effects on explicit import when "-S" was specified.

Yeah, it is a result of the fix for issue11591 (changeset a364719e400a).  Incidentally, the decision was made to forgo writing a testcase in favor of proof by inspection :-)

There are also other consequences of that change:

   ./python.exe -S
   Python 3.4.0a0 (default:08c215115842, Dec 30 2012, 09:54:54) 
   [GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.65))] on darwin
   >>> import site
   >>> quit()
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   NameError: name 'quit' is not defined
   >>> ^D

'quit' not being defined in this case is a regression.

ISTM the original change was meant to only prevent sys.path from being altered, but it is preventing a bunch of other things (USER_BASE, USER_SITE, quit, ...) from being initialized as well.

Whoops, the 'quit' case is actually intended and is documented (http://docs.python.org/3.4/library/site.html):

"""
or additions to the builtins. To explicitly trigger the usual site-specific additions, call the site.main() function.
"""

I think the right way to fix this is to use the accessor functions for the USER_* variables.  Does the attached look OK?

Patch works ok here, but should there be a test too?

It seems to me that -m site is not a guaranteed API but just a way to inspect/debug your installation/environment, so I wouldn’t add tests that make it looks like behavior is more defined than “print stuff about site dirs”.  I’d commit this simple fix as is (but then again, I’m responsible for the breakage :)

I will go ahead and commit the patch as is.  Thanks for the review y'all.

New changeset faa5d705c27d by Meador Inge in branch '3.3':
Issue #16804: Fix 'python -S -m site' failure.
http://hg.python.org/cpython/rev/faa5d705c27d

New changeset 8cbd8d8ac828 by Meador Inge in branch 'default':
Issue #16804: Fix 'python -S -m site' failure.
http://hg.python.org/cpython/rev/8cbd8d8ac828