On Fri, Jan 10, 2020 at 11:06:25PM -0800, Andrew Barnert wrote:
> On Jan 10, 2020, at 20:40, Steven D'Aprano <[email protected]> wrote:
[...]
> > Have I missed some subtlety in your proposal?
>
> Well, there are definitely subtle differences.
I'm sure there are, but it isn't clear to me that the proposed
enhancement has anything to do with the differences you mention.
> 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.
Well, sure, but when running as a script you are specifying a location,
and if you leave the extension off (assuming the script has one, which
it may not) then you are specifying a different, and probably
non-existing, location.
When using -m, you are telling Python to search for and run the named
module, and you have to use the same rules for legal module names as you
have to use inside the interpreter. And that means no extensions:
import math # not math.dll
I'm not concerned that the signatures are different:
python pathname # run the entity specified by the pathname
python -m module # run the module specified by the identifier
but whether between those two mechanisms (pick one or the other) it
solves Soni's issue. I think they might.
Soni suggested that you can't run a submodule in a package unless you cd
into the package, but I think that's wrong. I think that between the two
mechanisms for calling modules/packages/submodules, and the
"__main__.py" entry point to packages, this should cover pretty much all
the obvious use-cases for calling Python modules from the command line.
(Modulo any potential bugs in the implementation.)
I'm not worried about all the methods using precisely the same
interface, nor am I worried about subtle differences in the way the
various special variables argv[0], `__file__` etc are filled in.
(Those differences can be used by scripts/modules etc to identify how
they are called, in case they care.)
If Soni is worried about those things, they should say so, but I suspect
that they merely don't know about the `__main__.py` entry point. Or
perhaps I have completely misunderstood their proposal and I'm talking
nonsense.
> Wouldn’t it be simpler to just use a separate arg to add a path to the
> sys.path, or to cd to
Or we can learn to use your shell effectively. Does Python need to
offer equivalent ways of doing everything the OS shell provides? I hope
not :-)
In POSIX systems you can just set the PYTHONPATH for a single
invocation of the interpreter:
PYTHONPATH="/tmp" python whatever
As for the "cd to" option, you can get that with parentheses:
[steve@ando tmp]$ pwd
/tmp
[steve@ando tmp]$ (cd /; python3.5 -c "import os; print(os.getcwd())")
/
[steve@ando tmp]$
I assume Windows has equivalent features to the above. If not, then
perhaps we ought to consider what you say, but otherwise, let's not
duplicate shell features in the interpreter if we don't have a good
reason to do so.
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/QYRD753HKVFCDQCPY3DRBONSCR5FZDVL/
Code of Conduct: http://python.org/psf/codeofconduct/
