On Fri, Jan 10, 2020 at 10:24 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:

-----Original Message----- From: Steven D'Aprano <steve@pearwood.info> Sent: 11 January 2020 04:39 To: python-ideas@python.org Subject: [Python-ideas] Re: python -m quality of life improvements

On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L. wrote:

...

currently python -m requires you to cwd to the desired package root. I'd like to suggest the ability to python -m relative/path/to/package/root/module.submodule and python -m /absolute/path/to/package/root/module.submodule

Oh, a further thought comes to mind... if your modules aren't on the PYTHONPATH, just drop the -m and you can execute any legal Python file, even if the name isn't a legal identifier.

[steve@ando tmp]$ cp ~/python/spam/eggs.py /tmp/"some name".foo [steve@ando tmp]$ python3.5 "some name.foo" some name.foo

So as I understand it, the functionality you want already exists, both for running scripts on the path using -m and scripts with arbitrary file names without -m.

Have I missed some subtlety in your proposal?

[Steve Barnes] I did notice one anomaly in the behaviour of python -m: taking your code structure above and using :

...

py -mzipfile -c eggs.zip spam\__init__.py spam\__main__.py spam\eggs.py

to create eggs.zip I can run:

...

py eggs.zip

Renaming eggs.zip to eggs.py I can run:

...

eggs.py E:\toolbuild\eggs.py\__main__.py Or py eggs.py E:\toolbuild\eggs.py\__main__.py

But get problems when I try:

...

py -meggs.py Traceback (most recent call last): File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "C:\Python38_64\lib\runpy.py", line 109, in _get_module_details __import__(pkg_name) ValueError: source code string cannot contain null bytes

...

py -meggs Traceback (most recent call last): File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "C:\Python38_64\lib\runpy.py", line 153, in _get_module_details code = loader.get_code(mod_name) File "<frozen importlib._bootstrap_external>", line 916, in get_code File "<frozen importlib._bootstrap_external>", line 846, in

Gadget@GADGETLAPTOP E:\toolbuild source_to_code File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed ValueError: source code string cannot contain null bytes

Is this expected behaviour or worth a ticket and some time investigating further?

It's expected behaviour. Passing a file path to the interpreter goes through some special logic to look for a zip file, while -m is basically fancy importing.

On Fri, Jan 10, 2020 at 10:24 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:

-----Original Message----- From: Steven D'Aprano <steve@pearwood.info> Sent: 11 January 2020 04:39 To: python-ideas@python.org Subject: [Python-ideas] Re: python -m quality of life improvements

On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L. wrote:

...

currently python -m requires you to cwd to the desired package root. I'd like to suggest the ability to python -m relative/path/to/package/root/module.submodule and python -m /absolute/path/to/package/root/module.submodule

Oh, a further thought comes to mind... if your modules aren't on the PYTHONPATH, just drop the -m and you can execute any legal Python file, even if the name isn't a legal identifier.

[steve@ando tmp]$ cp ~/python/spam/eggs.py /tmp/"some name".foo [steve@ando tmp]$ python3.5 "some name.foo" some name.foo

So as I understand it, the functionality you want already exists, both for running scripts on the path using -m and scripts with arbitrary file names without -m.

Have I missed some subtlety in your proposal?

[Steve Barnes] I did notice one anomaly in the behaviour of python -m: taking your code structure above and using :

...

py -mzipfile -c eggs.zip spam\__init__.py spam\__main__.py spam\eggs.py

to create eggs.zip I can run:

...

py eggs.zip

Renaming eggs.zip to eggs.py I can run:

...

eggs.py E:\toolbuild\eggs.py\__main__.py Or py eggs.py E:\toolbuild\eggs.py\__main__.py

But get problems when I try:

...

py -meggs.py Traceback (most recent call last): File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "C:\Python38_64\lib\runpy.py", line 109, in _get_module_details __import__(pkg_name) ValueError: source code string cannot contain null bytes

...

py -meggs Traceback (most recent call last): File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "C:\Python38_64\lib\runpy.py", line 153, in _get_module_details code = loader.get_code(mod_name) File "<frozen importlib._bootstrap_external>", line 916, in get_code File "<frozen importlib._bootstrap_external>", line 846, in

Gadget@GADGETLAPTOP E:\toolbuild source_to_code File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed ValueError: source code string cannot contain null bytes

Is this expected behaviour or worth a ticket and some time investigating further?

It's expected behaviour. Passing a file path to the interpreter goes through some special logic to look for a zip file, while -m is basically fancy importing.