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.) _______________________________________________ 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/
