Hi Soni, For the last time, `python -m` takes a _module identifier_ as argument, not a path. For a module identifier to make sense, the `PYTHONPATH` must be set, or assumed.
Remember that you're free to write your own `mypython` script which takes whatever arguments you want, with whatever actions you need. Cheers! On Sat, Jan 11, 2020 at 7:02 PM Soni L. <fakedme...@gmail.com> wrote: > 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...@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...@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 >>> 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/L7RRKAML6GWYXN4ULLD3U2ZOLS6CC4HM/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> Juancarlo *Añez* >> >> >> > > -- > Juancarlo *Añez* > > > -- Juancarlo *Añez*
_______________________________________________ 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/OJ7VOMY5E2NE26MM4XEGXN7RFQYILGJB/ Code of Conduct: http://python.org/psf/codeofconduct/
