Comparison with defopt

[anntzer]

Hi,

I maintain the defopt argument parser generator (https://github.com/anntzer/defopt). I had a quick look at your comparison table in your docs) regarding how defopt compares with the other options:

• dataclasses: no
• functions: yes
• literals: yes (including mixed-type)
• docstrings as helptext: yes, with rich formatting of rst
• nested structures: no (because no dataclass support)
• unions: yes
• list, tuples: yes
• dicts: yes
• generics: no (because no dataclass support)

An idea that appears to be common to defopt and tyro is the use of a single function as entry point (tyro.cli, defopt.run). A difference, on the other hand, is that defopt is very much written in the "typing annotations should be generally valid, but are there first and foremost to generate the right CLI and not to pass typechecker checks" (to put it bluntly, I don't care much about type checkers).

A key feature that has been requested quite a few times on the defopt issue tracker is dataclass(-like) support, for which I had mostly been stuck due to not having a satisfactory syntax; for this I really like your idea of using --obj.attr, which, just as a heads up, I plan to reimplement (likely from scratch) in defopt.

Looking forward to discussing any relevant ideas on the topic!

[brentyi]

Hi @anntzer, thanks for sharing!

I just installed defopt and tried it out; it seems super comprehensive. I've had trouble keeping the internal complexity of tyro from ballooning and am also envious of your ~1200 line implementation!!

For dataclasses support: I can't take credit for the --obj.attr pattern unfortunately, there are libraries like simple-parsing where this existed before. But it's for sure super useful and I'm looking forward to seeing how your implementation turns out! Probably there are design improvements you can make over what we have in tyro; if you decide to support unions (DataclassA | DataclassB, DataclassA | int, DataclassA | None) this is where my biggest painpoints have come from.

defopt is very much written in the "typing annotations should be generally valid, but are there first and foremost to generate the right CLI and not to pass typechecker checks" (to put it bluntly, I don't care much about type checkers).

I'm also curious about is how this manifests in practice, does choosing to care vs not care about type checkers impact API choices at all? Or primarily internal implementation?