except I don't want to override PYTHONPATH. when you run a module with "python -m", it uses "." as one of the path elements. when you run a script with "python" it *doesn't use "." as one of the path elements*, instead replacing it with the path to the script. ideally "python -m" would also be able to check that you're running what you think you're running. maybe "python -m module.submodule@/path"? and then it'd check that "/path/module/submodule.py" or "/path/module/submodule/__main__.py" exists. and use "/path" instead of "." in the sys.path. I want a "python -m" clone with "python" semantics, basically. it makes development easier all around. and "python -m" provides a much nicer project structure than "python" IMO and I'd like to encourage ppl to switch their "python" projects to "python -m" projects. On 2020-01-11 7:28 p.m., Juancarlo Añez wrote:
Soni,
Others have explained it already. `python -m` expects a _module_ as parameter, and that module is searched by the rules `import` follows under `PYTHONPATH`.
What you're asking for is that `python` sets `PYTHONPATH` before executing a module. Maybe another option to `python`?
python -p /path/to -m foo
I would agree that would be nice.
On Sat, Jan 11, 2020 at 6:07 PM Soni L. <fakedme+py@gmail.com <mailto:fakedme%2Bpy@gmail.com>> wrote:
why are we allowed to have fancy `python /path/to/foo.py` but not fancy `python -m /path/to/foo`? 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.
so I propose we shove the solution into python -m instead. why's that so bad? it's simply ergonomics.
On 2020-01-11 6:28 p.m., Juancarlo Añez wrote:
Soni,
Perhaps what you're looking for is available by writing a short Python program with a shebang? Then PYTHONPATH would be set to the directory of the program (many small projects include a `run.py` in the project's base directory).
You can also place the program in ~/bin if it does `export PYTHONPATH`.
Then, I have this alias for one of my home-brewed tools, and it works as I want:
alias chubby='PYTHONPATH=~/chubby ~/.virtualenvs/chubby/bin/python -Oum chubby'
I too think that the semantics of `python -m` are fine.
On Sat, Jan 11, 2020 at 1:46 PM Soni L. <fakedme+py@gmail.com <mailto:fakedme%2Bpy@gmail.com>> wrote:
I just want python foo/bar/baz/qux/__main__.py but with imports that actually work. -m works, but requires you to cd. -m with path would be an more than huge improvement.
and it absolutely should look for the given module in the given path. not "anywhere in the PYTHONPATH".
On 2020-01-11 2:21 p.m., Steven D'Aprano wrote: > On Sat, Jan 11, 2020 at 11:27:51AM -0300, Soni L. wrote: > > > PYTHONPATH=foo/bar python -m baz.qux > > > > becomes > > > > python -m foo/bar/baz.qux > > > > which is less of a kludge. > > Sorry Soni, I completely disagree with you. > > The status quo `PYTHONPATH=foo/bar python -m baz.qux` is explicit about > changing the PYTHONPATH and it uses a common, standard shell feature. > This takes two well-designed components that work well, and can be > understood in isolation, and plugging them together. The first part of > the command explicitly sets the PYTHONPATH, the second part of the > command searches the PYTHONPATH for the named module. > > Far from being a kludge, I think this is elegant, effective design. > > It seems to me that your proposed syntax is the kludge: it mixes > pathnames and module identifiers into a complex, potentially > ambiguous "half path, half module spec" hybrid: > > foo/bar/baz.qux > * foo/bar/ is a pathname > * baz.qux is a fully-qualified module identifier, not a file name > > The reader has to read that and remember that even though it looks > exactly like a pathname, it isn't, it does not refer to the file > "baz.qux" in directory "foo/bar/". It means: > > * temporarily add "foo/bar/" to the PYTHONPATH > * find package "baz" (which could be anywhere in the PYTHONPATH) > * run the module baz.qux (which might not be qux.py) > > _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@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/L7RRKA... Code of Conduct: http://python.org/psf/codeofconduct/
-- Juancarlo *Añez*
-- Juancarlo *Añez*