[issue8202] sys.argv[0] and python -m package

Changes by Nick Coghlan : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: Implemented in r84140. Leaving issue open until the buildbots give it a clean bill of health (since the command line tests can be a little quirky when it comes to cross platform differences) -- resolution: -> accepted stage: unit test needed -> commit

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: Reverted in r81964, marking as 3.2 only. For 3.2, I'll get rid of the hack by having SetArgV treat both "-c" and "-m" as special values for sys.argv[0], and by adding some unit tests that make sure the presence of files with those names has no effect on the val

[issue8202] sys.argv[0] and python -m package

Benjamin Peterson added the comment: Revert seems sensible in this situation. -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: Grr, in doing the Py3k forward port I found the hack based on the "-c" entry that I remembered (I had mentioned it *right there* in a comment in main.c, so I don't know how I missed it when first updating 2.7 - I suspect I got lost in the ifdef maze inside SetA

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: Committed for 2.7 in r80580 (as it turns out, the hack I remembered was probably from the original pre-runpy 2.4 implementation and has since been replaced by the proper runpy based system. This bug was likely just a lingering remnant of that original hackish a

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: I realised today that this behaviour is actually the case for any execution of a module inside a package with -m (i.e. any __init__ modules execute before sys.argv and __main__ are fully configured). As I recall, I used a bit of a hack to get main.c to implemen

[issue8202] sys.argv[0] and python -m package

Michael Foord added the comment: '-c' isn't helpful because that is also the content of sys.argv[0] when a module is imported in response to "python -c '...'". -- ___ Python tracker ___

[issue8202] sys.argv[0] and python -m package

Michael Foord added the comment: I've already fixed my specific usecase (for unittest), but a special value in sys.argv[0] would indeed have met my needs. -- ___ Python tracker

[issue8202] sys.argv[0] and python -m package

Brett Cannon added the comment: Nick is right that importing package.__main__ requires importing package.__init__ first. But it sounds like Michael really just wants some way to know when runpy is being used over something else. Could a special string token like "" or "<-m>" be placed in sys

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: Hmm, the problem here is we don't *know* the module filename until we get hold of the loader for it (see _get_module_details() in runpy). And it is the process of finding the loader for the __main__ module that does the initial import of the package as a side e

[issue8202] sys.argv[0] and python -m package

New submission from Michael Foord : When you execute "python -m package" the package is first imported with sys.argv[0] set to '-c' (and sys.modules['__main__'] exists but is empty. Then package.__main__.py is executed with the correct sys.argv[0]. This means module level code executed during