Document how to have variadic positional arguments without a leading flag

[rec]

Thanks for your work on this very exciting CLI parser.

See #39, which does not appear to cover this.

I want to create a command fing which combines several files, with a usage like this:

usage: fing [-h] PATH [PATH ...]

but the naïve:

def main(*files: Path) -> None:
    print(*files)

gives

usage: /Users/tom/code/fing/fing/__main__.py [-h] [--files [PATH [PATH ...]]]

I don't see any examples of a command which doesn't use flags, and I see this unit test seemingly confirming this behavior.

After some fiddling, I found out that this works:

def main(files: list[Path], /) -> None:
    print(files)

but this doesn't:

def main(files: list[Path]) -> None:
    print(files)

and of course, this isn't even correct Python:

def main(*files: Path, /) -> None:
    print(files)

---

The above workaround seems very reasonable once you know it: I'm suggesting that it be documented somewhere around https://brentyi.github.io/tyro/examples/basics/#positional-arguments

[brentyi]

Thanks for the note! Agree that we should document this, I can do it.

The behavior you expected originally for *args also seems reasonable, I remember debating it. For context, here's the comment from the original *args and **kwargs implementation that explains why --args and --kwargs get created:

            # it would be straightforward to make both this and *args truly
            # positional, omitting the --args/--kwargs prefix, but we are choosing not
            # to because it would make *args and **kwargs difficult to use in
            # conjunction.

[rec]

Heh, I already read that comment!, but I'd actually worked out the reason on my own: that there are two possible interpretations for

def f(*a: str, **ka: str) -> None:

and "a is a flag" is closer to the other interpretations of variables here, though typer does it the other way.

---

If you were interested in what people preferred, you could consider enabling the other behavior with a feature flag/annotation somewhere, put it in the docs, and then in a year or two, search github to see how many people were using that feature flag.

I have some spare time coming up, I could put implementing that on my agenda.

---

You will be amused that some years ago I was sufficiently peeved by how typer did what you're doing correctly that I wrote my own band-aid for it that fixed some of its issues: https://pypi.org/project/dtyper/

I am deprecating it, though; it was impossible to get the type annotations right (I think in 3.12 it's possible but hard), and tyro does the trick much better.

---

Since I have you on the line: for a new project, cattrs vs Pydantic with respect to tyro, which would you pick?

[rec]

Oh, sorry, another minor tweak:

def main(files: list[str], /) -> None:
    print(files)

results in

usage: test_tyro.py [-h] [STR [STR ...]]

╭─ positional arguments ───────────────────────────╮
│ [STR [STR ...]]  files (required)                │
╰──────────────────────────────────────────────────╯
╭─ options ────────────────────────────────────────╮
│ -h, --help       show this help message and exit │
╰──────────────────────────────────────────────────╯

But files is not actually required.

If you want "one or more files", then this works:

def main(file: str, files: list[str], /) -> None:
    print(files)

But the usage is also a little off, as the remaining files are not required.

python test_tyro.py -h
usage: test_tyro.py [-h] STR [STR [STR ...]]

╭─ positional arguments ───────────────────────────╮
│ STR              file (required)                 │
│ [STR [STR ...]]  files (required)                │
╰──────────────────────────────────────────────────╯

[brentyi]

Typer behavior: yeah, in retrospect I actually prefer their approach. It's closer to the Python semantics, and now that we've written the CLI parsing backend from scratch, it feels like we can do better than --kwargs K V K V ... for **kwargs. If we do a 2.0 release eventually maybe these things will change, in the meantime I think 99%+ of tyro users never consider using *args or **kwargs, so it's okay.

dtyper: thanks for sharing, it's a cool project! I've also thought about trying to reimplement typer's API as a wrapper over tyro, but the details are tricky.

cattrs vs pydantic: to be honest I don't work very closely with either, but cattrs feels lighter and is compatible with standard dataclasses so I would reach for it first! But it does seem like pydantic is "winning" in terms of broader adoption.

Finally, thanks for sharing on the required bug. Will have it fixed in the next release!!

[rec]

Nah, dtyper is a bad hack. 😁 It was one of my last untyped Python projects. It was very useful, and I got paid to do it, but the moment I started using typing, I felt silly.

pydantic does appear to be winning. I seriously damaged my position in a company by adopting it, right when they were going to version 2, and 2.0, 2.1 and 2.2 turned out to be mutually incompatible. Since we were a library, we had immense issues with other projects depending on our library that also used a different version of pydantic.

blah blah. Thanks for a great project, I'll be using it exclusively in future!

Oh, and I did this: https://www.reddit.com/r/Python/comments/1rv7agv/a_quick_review_of_tyro_a_cli_library/