On 2020-01-11 8:33 p.m., Andrew Barnert wrote:
On Jan 11, 2020, at 14:09, Soni L. <fakedme...@gmail.com> wrote:
>
> why are we allowed to have fancy `python /path/to/foo.py` but not fancy `python -m /path/to/foo`?
There’s nothing fancy about the first one. It’s a path, and it’s up to your OS
what a path means. It’s exactly the same as passing a path to sh or cmd or
ffmpeg or any other tool.
The argument to -m is also not fancy, because it’s not a path at all, it’s a
module name. Which means Python searches the PYTHONPATH for a module with that
name.
What you’re asking for is something that’s a path up to some point (even though
your shell can’t tell) and then switches to being a module name at some
unspecified point in the middle. For your trivial case it’s obvious where you
want that point to be, but what’s the rule that handles non-trivial cases that
aren’t obvious? And, even if there is a rule that’s easily understandable and
unambiguous (to humans, to Python, to shell completers, etc.), why is that
better than having separate arguments for the path and the module name in the
first place?
> if `python` was capable of detecting modules and automatically deciding package roots,
none of this would even be an argument and I'd just use `python
/path/to/module/submodule/__main__.py` (with "module" having an __init__.py) and
be done with it. but python can't do that because backwards compatibility and whatnot.
It’s nothing to do with backward compatibility. Any directory is a package.
(There are also packages that aren’t even directories, but ignore that extra
complexity here.) If it doesn’t have an __init__.py, it’s a namespace package,
which is still a package. That same path is just as validly interpreted five
different ways, from path.to.module.submodule.__main__ in directory / to
__main__ in directory /path/to/module/submodule. What possible rule could tell
Python which of those five you’re intending, short of reading your mind?
A human can do some limited mind reading. Usually you don’t have modules named
”__main__” except as the main script of a package; “module” sounds like a good
name for a module but “to” doesn’t; people rarely use hierarchies more than 2
or 3 deep for packages but often do use deep hierarchies for filesystem paths;
etc. But even a human can’t guess for a case like spam/eggs/cheese.py which one
of those is the root.
A solution that made it easier to tell Python that something is a package would
solve your problem without requiring magic telepathy, and without breaking
modules. The obvious way to do that is to put its parent directory on the
PYTHONPATH. I don’t understand why you don’t like that, but I suppose you could
just as easily have a mechanism that says “this directory is a package just as
if its parent were on the PYTHONPATH even though it isn’t”. But I don’t see why
making Python and the reader and the shell split a hybrid path into
hierarchical fs path and hierarchical module path according to some rule you
can’t even tell us is supposed to make that any easier for anyone.
algorithm for -m idea:
def find_package_root_and_module_name(argm: Path):
return (argm.parent, argm.name)
algorithm for non -m idea:
def find_package_root_and_module_name(argv0: Path):
argv0 = argv0.resolve()
package_root = argv0.parent # or however we resolve the package_root
today
if argv0.suffix != "py":
return (package_root, None)
module_name = argv0.stem # may be __main__!
while package_root.exists():
if (package_root / '__init__.py').exists():
module_name = f"{package_root.name}.{module_name}"
package_root = package_root.parent
else:
return (package_root, module_name)
raise ??? # this means every directory up to the
root/drive/filesystem root/whatever is a package. there is no package
root so just raise.
_______________________________________________
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/V7JGTUT33UOTVS5OFBDOPBUBU5R7CSML/
Code of Conduct: http://python.org/psf/codeofconduct/