This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Jonathan Huot, docs@python, ncoghlan, terry.reedy
Date 2018-03-24.01:15:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1521854122.05.0.467229070634.issue33119@psf.upfronthosting.co.za>
In-reply-to
Content
Two of your 3 suggested alternatives could lead to bugs. To use your example:
 python -m mainmodule.submodule.foobar -o -b
is a convenient alternative and abbreviation for
 python .../somedir/mainmodule/submodule/foobar.py -o -b
The two invocations should give equivalent results and to the extent possible the same result.

[What might be different is the form of argv[0].  In the first case, argv[0] will be the "preferred" form of the path to the python file while in the second, it will be whatever is given.  On Windows, the difference might look like 'F:\\Python\\a\\tem2.py' versus 'f:/python/a/tem2.py']

Unless __init__.py does some evil monkeypatching, it cannot affect the main module unless imported directly or indirectly.  So its behavior should be the same whether imported before or after execution of the main module.  This means that argv must be the same either way (except for argv[0]).  So argv[0:2] must be condensed to one arg before executing __init__.  I don't see that '' is an improvement over '-m'.

Command line arguments are intended for the invoked command.  An __init__.py file is never the command unless invoked by its full path: "python somepath/__init__.py".  In such a case, sys.argv access should be within a "__name__ == '__main__':" clause or a function called therein.
History
Date User Action Args
2018-03-24 01:15:22terry.reedysetrecipients: + terry.reedy, ncoghlan, docs@python, Jonathan Huot
2018-03-24 01:15:22terry.reedysetmessageid: <1521854122.05.0.467229070634.issue33119@psf.upfronthosting.co.za>
2018-03-24 01:15:21terry.reedylinkissue33119 messages
2018-03-24 01:15:19terry.reedycreate