Re: CLI parsing—with `--help` text—`--foo bar`, how to give additional parameters to `bar`?
The feature that existing CLI parsers are missing is a clean syntax
for specifying options on the second parameter (the "value"), where
there may be different options available depending on which you
has `learning_rate`, `beta_1`, `beta_2`, `epsilon`, and `amsgrad`*
has `learning_rate`, `rho`, `momentum`, `epsilon`, `centered`*
*with clipnorm, clipvalue, decay hidden behind kwargs
So the question is how to expose this as CLI options. `--optimizer
Adam` is a good first step, but it should error if I try and give it
`momentum`. The comma syntax is my favourite so far.
I guess I'll just have to write a validator outside the CLI parser to
Charity <https://sydneyscientific.org> | consultancy
<https://offscale.io> | open-source <https://github.com/offscale> |
On Fri, Oct 16, 2020 at 11:19 AM <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
> On 2020-10-16 at 10:20:40 +1100,
> Cameron Simpson <cs at cskk.id.au> wrote:
> > On 16Oct2020 10:09, Samuel Marks <samuelmarks at gmail.com> wrote:
> > >Yes it?s my module, and I?ve been using argparse
> > >https://github.com/SamuelMarks/ml-params
> > >
> > >No library I?ve found provides a solution to CLI argument parsing for my
> > >use-case.
> Out of curiosity, what do your command line interfaces require that
> argparse and other libraries don't have?
> Yes, if my only tool is a hammer, then every problem looks like a nail,
> but I've yet to have a requirement that the POSIX rules don't cover.
> > >So I?ll write one ...
> Been there. Done that. :-)
> > > [...] But what should it look like, syntactically and semantically?
> > In particular, I would not invent yet another command line syntax.
> I agree. The POSIX Utility Syntax and Guidelines:
> (I believe argparse supports a superset of the POSIX syntax.)
> I haven't found a definitive definition of GNU long options, only