None of this is even about relative imports. Absolute imports are also
broken between them, as I tried to demonstrate using my project
structure. The *whole* import system breaks.
On 2020-01-12 3:12 p.m., Brendan Barnwell wrote:
On 2020-01-11 23:34, Steven D'Aprano wrote:
On Sun, Jan 12, 2020
On 2020-01-11 23:34, Steven D'Aprano wrote:
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 e
On Jan 12, 2020, at 06:10, Soni L. wrote:
>
> And yes this is a real project structure. Also note that there's no setup.py
> because setup.py has too many unnecessary knobs
Who cares what knobs it has? The ones you don’t need to twiddle don’t matter.
For most projects, writing an appropriate s
PS: typoed "~/git" as "~/.git", oops.
sorry.
On 2020-01-12 11:09 a.m., Soni L. wrote:
Consider a directory structure like this one:
ganarchy/
├── cli
│ ├── debug.py
│ ├── __init__.py
│ └── __pycache__
├── config.py
├── __init__.py
├── __main__.py
└── __pycache__
abdl/
├── exceptions.py
├
Consider a directory structure like this one:
ganarchy/
├── cli
│ ├── debug.py
│ ├── __init__.py
│ └── __pycache__
├── config.py
├── __init__.py
├── __main__.py
└── __pycache__
abdl/
├── exceptions.py
├── __init__.py
├── _parser.py
├── __pycache__
├── validators.py
└── _vm.py
If one cd'd t
On Sun, Jan 12, 2020 at 6:38 PM Steven D'Aprano wrote:
>
> 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 executin
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 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 (o
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 (or,
>
> 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 spam/
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 response
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 means.
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 or
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 action
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 b
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 /pat
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 PY
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:2
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
changi
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 python
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
enhance
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 t
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 python -m
>> relative/path/to/package/root/module.submodule and python -m
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 python -m
> relative/path/to/package/root/module.submodule and python -m
> /absolute/path/to/package/root/module.submodule
What d
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 python -m
> relative/path/to/package/root/module.submodule and python -m
> /absolute/path/to/package/root/module.submodule
Oh, a f
28 matches
Mail list logo