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
<mailto:fakedme%2...@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
<mailto:fakedme%2...@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-le...@python.org
<mailto: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*
_______________________________________________
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/OMQEJSHVO7LX2HZ5QONG7M4AGGCDCYIU/
Code of Conduct: http://python.org/psf/codeofconduct/
