On Sun, Jan 12, 2020 at 11:59:20AM +1100, Chris Angelico wrote:
> The biggest difference is that scripts can't do relative imports.
How is that relevent? People keep mentioning minor differences between
different ways of executing different kinds of entities (scripts,
packages, submodules etc) but not why those differences are important or
why they would justify any change in the way -m works.
A script can't do relative imports because they aren't packages and so
don't have any submodules that they could do a relative import of.
If relative imports are important to you, why not use a package?
(I don't want to keep saying this, so I will say it only once: none
of my questions in this post are rhetorical questions.)
Or have the script adjust the path itself. Say I want to package up a
bunch of related scripts and libraries, so I create this structure:
myscripts/
+-- spam.py
+-- eggs.py
+-- cheese.py
but I want spam to be able to import eggs and cheese, and vice versa,
the obvious solutions (in order of decreasing obviousness) are:
* Just use a package.
* Set the PYTHONPATH from the command line:
PYTHONPATH='myscripts/' python -m spam
* Have each module insert its parent directory on the path:
import pathlib, sys
sys.path.insert(0, pathlib.Path(__file__).parent.absolute())
There may be pros and cons of each approach, there may even be slight
differences in behaviour, but is there some reason why none of these
are satisfactory and the only solution is special support from the
interpreter?
> So
> here's a counter-proposal: Allow "from . import modulename" to import
> "modulename.py" from the directory that contains the script that
> Python first executed (or, for interactive Python, the current
> directory as Python started).
I wish people wouldn't jump straight to proposing solutions before they
have articulated the specific nature of the problem they wish to solve
first :-(
(This isn't aimed *specifically* at Chris, it is a general observation.)
Even if the problem is blindingly obvious to (generic) you, it may not
be obvious to all of us. We shouldn't get twenty posts into a thread
and have the problem being solved still be unclear.
Why is it necessary to use a relative import in a non-package script? Is
this a way to solve name collisions?
"I want a script spam.py that depends on a module X.py, but X clashes
with a standard library module, and I need both the stdlib X and the
local X."
I think a dotted import would work (but so would renaming X) and the
obvious way to make the dotted import work is to put spam.py and X.py
into a package.
--
Steven
_______________________________________________
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/IEBNVP3KWODIFDHI52FUHAAAY4JEGNQN/
Code of Conduct: http://python.org/psf/codeofconduct/
