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)
On Sat, Jan 11, 2020 at 11:03 AM Kyle Stanley wrote:
>
> > 1. Recommend it in the official document "Using Python on Windows" [2].
> > 2. Show the UTF-8 mode status in the command line mode header [3] on
> > Windows.
> > 3. Show the link to the UTF-8 mode document in the command line mode header
On Sun, Jan 12, 2020 at 12:30 PM Juancarlo Añez wrote:
>>
>> The biggest difference is that scripts can't do relative imports. 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
On 2020-01-11 10:30 p.m., Juancarlo Añez wrote:
The biggest difference is that scripts can't do relative imports. 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
>
> The biggest difference is that scripts can't do relative imports. 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
On Sun, Jan 12, 2020 at 11:10 AM Steven D'Aprano wrote:
> You seem to be asking to weld a screwdriver head to a hammer so that you
> can have the hammer behave like a screwdriver. If you know the precise
> path you want to run, why are you using
>
> # your proposed syntax
> python -m
On 2020-01-11 9:01 p.m., Steven D'Aprano wrote:
On Sat, Jan 11, 2020 at 02:46:14PM -0300, Soni L. 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.
That's
On Sat, Jan 11, 2020 at 02:46:14PM -0300, Soni L. 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.
That's what you said in your first post. In my first
On 2020-01-11 8:33 p.m., Andrew Barnert wrote:
On Jan 11, 2020, at 14:09, Soni L. wrote:
>
> why are we allowed to have fancy `python /path/to/foo.py` but not fancy `python -m /path/to/foo`?
There’s nothing fancy about the first one. It’s a path, and it’s up to your OS
what a path
On Jan 11, 2020, at 14:09, Soni L. wrote:
>
> why are we allowed to have fancy `python /path/to/foo.py` but not fancy
> `python -m /path/to/foo`?
There’s nothing fancy about the first one. It’s a path, and it’s up to your OS
what a path means. It’s exactly the same as passing a path to sh
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
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
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
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
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
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
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
On Fri, Jan 10, 2020 at 10:24 PM Steve Barnes
wrote:
>
>
> -Original Message-
> From: Steven D'Aprano
> Sent: 11 January 2020 04:39
> To: python-ideas@python.org
> Subject: [Python-ideas] Re: python -m quality of life improvements
>
> On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L.
On 2020-01-11 4:06 a.m., Andrew Barnert via Python-ideas wrote:
On Jan 10, 2020, at 20:40, Steven D'Aprano wrote:
>
> On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L. wrote:
>> currently python -m requires you to cwd to the desired package root. I'd
>> like to suggest the ability to
On Fri, Jan 10, 2020 at 11:06:25PM -0800, Andrew Barnert wrote:
> On Jan 10, 2020, at 20:40, Steven D'Aprano 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
On Sat, Jan 11, 2020, at 02:06, Andrew Barnert via Python-ideas wrote:
> Well, there are definitely subtle differences. 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. If you -m a package, argv[0] is the
> path
21 matches
Mail list logo
