defopt icon indicating copy to clipboard operation
defopt copied to clipboard

feature request: support positional argument of type Sequence in additional to *args

Open ickc opened this issue 3 years ago • 6 comments

MWE

from dataclasses import dataclass

import defopt


def main(
    args: list[str],
):
    pass


def ok(
    *args: str,
):
    pass


@dataclass
class Main:
    args: list[str]


@dataclass
class Ok:
    arg: str


if __name__ == "__main__":
    defopt.run(
        (main, ok, Main, Ok),
        strict_kwonly=False,
    )

resulted in

❯ python example.py ok -h                          
usage: example.py ok [-h] [args ...]

positional arguments:
  args

optional arguments:
  -h, --help  show this help message and exit
❯ python example.py main -h
usage: example.py main [-h] -a [ARGS ...]

optional arguments:
  -h, --help            show this help message and exit
  -a [ARGS ...], --args [ARGS ...]
❯ python example.py Main -h
usage: example.py Main [-h] -a [ARGS ...]

Main(args: list)

optional arguments:
  -h, --help            show this help message and exit
  -a [ARGS ...], --args [ARGS ...]
❯ python example.py Ok -h  
usage: example.py Ok [-h] arg

Ok(arg: str)

positional arguments:
  arg

optional arguments:
  -h, --help  show this help message and exit

Notes

The feature request is to support main(args: list[TypeX], *, ...) to be equivalent in terms of defopt to main(*args: TypeX, ...).

In the function case, main, the user could have written it as the function ok instead.

In the dataclass case however, since Python's dataclass doesn't support variable positional arguments, one cannot defines *args. So the only sensible choice here is to define args: list instead.

ickc avatar Dec 04 '21 01:12 ickc

Thanks for the suggestion. Let's keep the discussion in #95 for now, as I think the two requests share some points.

anntzer avatar Dec 05 '21 14:12 anntzer

? I think they are completely different issue? This one is about how positional arg: list[...] should be treated the same as *args: .... #95 is about allowing appending when the same keyword arg is repeated.

ickc avatar Dec 06 '21 23:12 ickc

I read your comments in #95 and now I understand you're proposing using a similar solution to tackle 2 different issues.

ickc avatar Dec 06 '21 23:12 ickc

Copied from #95:

This and #96 both seem reasonable to me, but adding a global option to defopt.run seems unsatisfying because sooner or later someone will request to be able to specify this only for some of the parameters, perhaps in some deeply nested subcommands hierarchy on top of that...

Off the top of my head, a possibly(?) better solution could be to exploit typing.Annotated here, e.g. Annotated[list[int], defopt.APPEND] here and Annotated[list[int], defopt.VARARGS] for #96. (Note that for the case here, the underlying type annotation should be list[int], not int, because that's what the type of foo would ultimately be in the program.) A PR would be welcome :-) It should also clarify how these options interact with cli_options, as introduced by #92 (which is generalizing strict_kwonly).

ickc avatar Dec 07 '21 01:12 ickc

Sorry, giving up for now. I don't seem to understand the design of defopt.

For example,

#!/usr/bin/env python

from typing import Annotated
from inspect import Parameter

import defopt

def main(args: Annotated[list[str], Parameter.VAR_POSITIONAL]):
    pass

if __name__ == "__main__":
    defopt.run(main)

In _populate_parser, I get the following

param.annotation == typing.List[str]
getattr(param.annotation, "__metadata__", []) == []

It doesn't seem to be able to get the Annotated types and its metadata.

ickc avatar Dec 07 '21 02:12 ickc

Right now there is no support for Annotated at all, the suggestion is also to add such support.

anntzer avatar Dec 07 '21 07:12 anntzer