[issue16737] Different behaviours in script run directly and via runpy.run_module

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16737] Different behaviours in script run directly and via runpy.run_module

Jason R. Coombs added the comment: I've filed a separate request here for the sys.path[0] aspect: https://bugs.python.org/issue31874 -- ___ Python tracker

[issue16737] Different behaviours in script run directly and via runpy.run_module

Isaiah Peng added the comment: Not sure if it's stated before, this difference of behavior also has other effects, e.g. $ python -m test.test_traceback # Ran 61 tests in 0.449s # FAILED (failures=5) This is because the loader associated with the module get confused, it

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: Yeah, that one I definitely think could be improved. Could you file a separate RFE suggesting that we update sys.path[0] based on __main__.__spec__.origin after we look up __main__.__spec__? That way it will only stay as the current

[issue16737] Different behaviours in script run directly and via runpy.run_module

Jason R. Coombs added the comment: The other major difference and the only one that's affected me is the presence of sys.path[0] == ''. -- ___ Python tracker

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: Is there a relevant discrepancy other than __file__ sometimes being absolute? If code wants to be certain that __file__ is relative to the current directory, they need to run it through os.relpath() - there's no requirement for

[issue16737] Different behaviours in script run directly and via runpy.run_module

Jason R. Coombs added the comment: > All of the differences in semantics make total sense when you realize `-m > pkg` is really conceptually shorthand for `import pkg.__main__` (w/ the > appropriate __name__ flourishes). > So instead of selling `-m` as a way to run a

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: Something we don't really have anywhere is a short summary of how sys.path[0] gets initialised - it's scattered through the descriptions of the various invocation options in https://docs.python.org/3/using/cmdline.html#interface-options I figure it's also

[issue16737] Different behaviours in script run directly and via runpy.run_module

Brett Cannon added the comment: Maybe we just need to clarify some documentation at this point? All of the differences in semantics make total sense when you realize `-m pkg` is really conceptually shorthand for `import pkg.__main__` (w/ the appropriate __name__ flourishes). When you begin to

[issue16737] Different behaviours in script run directly and via runpy.run_module

Jason R. Coombs added the comment: I've found some other inconsistencies with the use of python -m. One is the surprising behavior when running pip: $ touch logging.py $ pip --help > /dev/null $ python -m pip --help > /dev/null Traceback (most recent call last): File

[issue16737] Different behaviours in script run directly and via runpy.run_module

Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16737 ___ ___ Python-bugs-list

[issue16737] Different behaviours in script run directly and via runpy.run_module

Brett Cannon added the comment: Just to have this written down somewhere, site.py already goes through and changes __file__ to absolute for modules already imported before it is run, so there is some precedent to not caring about relative file paths. --

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: Ah, some glorious (in)consistency here: $ cat echo_file.py print(__file__) (2.7, old import system) $ python -c import echo_file echo_file.pyc $ python -m echo_file /home/ncoghlan/devel/play/echo_file.py $ python echo_file.py echo_file.py (3.2, cache

[issue16737] Different behaviours in script run directly and via runpy.run_module

Nick Coghlan added the comment: So yes, any code that assumes __main__.__file__ is a relative path is just plain wrong, as Python provides no such guarantee. It may currently be either relative or absolute at the implementation's discretion. If the status quo ever changes, it would be to

[issue16737] Different behaviours in script run directly and via runpy.run_module

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16737 ___

[issue16737] Different behaviours in script run directly and via runpy.run_module

Brett Cannon added the comment: I would totally support tossing relative file paths in Python 3.4 as it has been nothing but backwards-compatibility headaches and is essentially wrong as the module's file is not relative to the current directory necessarily. --

[issue16737] Different behaviours in script run directly and via runpy.run_module

Éric Araujo added the comment: FTR, distutils only recommends and supports running “python setup.py”, i.e. relative path in the script’s directory. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16737

[issue16737] Different behaviours in script run directly and via runpy.run_module

Vinay Sajip added the comment: FTR, distutils only recommends and supports running “python setup.py”, i.e. relative path in the script’s directory. Right, but this behaviour is seen even when the script is in the current directory. -- ___ Python

[issue16737] Different behaviours in script run directly and via runpy.run_module

New submission from Vinay Sajip: If a script is run directly, the value of __file__ in it is relative to the current directory. If run via runpy.run_module, the value of __file__ is an absolute path. This is a problem in certain scenarios - e.g. if the script is a distribution's setup.py, a

[issue16737] Different behaviours in script run directly and via runpy.run_module

Serhiy Storchaka added the comment: $ ./python -m script /home/serhiy/py/cpython/script.py __main__ $ ./python -c import runpy; runpy.run_path('script.py', run_name='__main__') script.py __main__ This looks consistent. -- nosy: +serhiy.storchaka ___

[issue16737] Different behaviours in script run directly and via runpy.run_module

Vinay Sajip added the comment: I'd use runpy.run_path if I could, but it's not available on Python 2.6 - that's why I'm using run_module. A lot of setup.py files out there use __file__ to compute additional package names, package data locations etc. - this can lead to bogus package names

[issue16737] Different behaviours in script run directly and via runpy.run_module

Serhiy Storchaka added the comment: I'm just pointing that run_module() and run_path() differs in the same way as `python -m` and `python`. If you want to change behavior of run_module(), then you should to change behavior of `python -m` too. And I'm not sure that this change will not break a