On 2020-01-11 4:06 a.m., Andrew Barnert via Python-ideas wrote:
On Jan 10, 2020, at 20:40, Steven D'Aprano <st...@pearwood.info> wrote:
>
> 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?
Well, there are definitely subtle differences. If it’s a single file rather
than a package, running it as a script means you have to include the extension;
with -m you can’t. If you -m a package, argv[0] is the path to its __main__.py;
if you run a package as a script it’s the path to the package. If you -m the
parent directory of the package obviously has to be on sys.path, but if you run
it as a script, it generally won’t be. There might also be differences with
which paths (argv[0], __file__, __cached__, etc.) get abspathed on each
platform (I can never remember the rules for that anyway). Do they both work
with namespace packages? Fire the same auditing events? Interact the same way
with the Windows py.exe launcher and shbang lines? Does -m ignore case on *nix
on case-insensitive filesystems? What if you’ve got weird stuff in your
metapath from a site-installed import hook? I don’t know the answers for most
of these.
Of course part of the reason I don’t know the answers is that I don’t think
I’ve ever had a case where any of these differences mattered. But I could
imagine there might be one.
But really, 80% of the time, people who are asking for anything like this
actually have a perfect use case for building a setuptools-installable package
(maybe even with a generated entry-point script) and just don’t know it. A lot
of people think it’s really hard if they’ve never done it, or that it’s only
appropriate for stuff you want to publish on PyPI, or whatever.
Anyway, I don’t really like the proposal as given even if there is a use for
it. Mixing the module hierarchy and the file system hierarchy like that seems
like a recipe for confusion—if not in the interpreter (and the shell’s tab
completer) then at least in the human reader. Is a\b.c/d.e module e in package
d in directory a\b.c\, or module e in (invalid) package c/d in package b in
directory a\, or what? In this case, I think only one of the ambiguous ways you
could read that is actually valid, but surely the rule can’t be “parse it every
way and pick one of the valid ones arbitrarily”. (And imagine the confusion if
your package has a module named py or pyw.)
Wouldn’t it be simpler to just use a separate arg to add a path to the
sys.path, or to cd to, or to use in place of sys.path for finding the main
module? (Without knowing the intended use I don’t know which of those is
appropriate, but I’m guessing one of them is.)
PYTHONPATH=foo/bar python -m baz.qux
becomes
python -m foo/bar/baz.qux
which is less of a kludge. and baz.qux can still import stuff on the
foo/bar "package root", so e.g. it could "import baz" or "import
something_else_entirely".
This is for development (or running things straight off the dev
environment), not deployment.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/U4RXB6ANG4ICNLQ47V67SJEZDRKR7UED/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BJPQLW6I3YVP6WM3GE67EY6FU3YMKWLO/
Code of Conduct: http://python.org/psf/codeofconduct/
