Re: [PATCH] Complete python module arguments

["Ronan Pigott" <ronan@xxxxxx>]

February 27, 2025 at 8:52 AM, "Oliver Kiddle" <opk@xxxxxxx> wrote:

> This looks like a good idea to me.
> 
> Our usual convention on naming of completion functions tends to use a
> 
> hyphen before the name of subcommands so, e.g. _git-reset completes for
> 
> git reset while helper functions have names like _git_modified.
> 
> Submodules are more similar to subcommands so this would imply a naming
> 
> convention of, e.g. _python_module-venv
> 
> Or if the underscore / hyphen mix is too ugly, we could perhaps consider
> 
> something like _pymodule-venv or _python-venv.

I'm fine with _python_module-venv, let's go with that.

> On my system, python3 -m venv -h also lists --system-site-packages and
> 
> --prompt options. -h - --help is perhaps fairly ubiquitous and could
> 
> be completed even where a custom function is not found (in addition to
> 
> default file completion).
> 
> And I think _directories would be a suitable completion for 'virtual
> 
> environment'.

Oh whoops, mine too. Actually I wrote this a while ago and only just now
decided to send upstream and I guess I omitted the arguments I never use
but I'll update it to be accurate as of python 3.13.2.
 
> The convention for descriptions is not to capitalise the first word.
> 
> Can a python module name as passed to -m contain any problematic
> 
> characters such as / or any that might have a special meaning to python
> 
> . perhaps?

Python module names must be valid python identifiers [1][2] (they are assigned to
that name when imported afterall), however the argument to -m may also be a
submodule, so module.submodule is valid e.g. `python -m http.server` is such
a submodule. I've just tried it and TIL "." is valid in a zsh function name, so
maybe it's good as is? Or do you think it should be mangled somehow?

[1] https://docs.python.org/3/reference/lexical_analysis.html#identifiers
[2] https://docs.python.org/3/reference/simple_stmts.html#the-import-statement