Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing a required argument by name #146

Closed
neithere opened this issue Apr 15, 2021 · 1 comment
Closed

Passing a required argument by name #146

neithere opened this issue Apr 15, 2021 · 1 comment

Comments

@neithere
Copy link
Owner

Background

Argh follows Argparse's grouping of arguments into two bunches:

  • "Positional" = determined by position and required (possibly optional with nargs set to ? or *)
  • "Optional" AKA "options" = determined by name e.g. --foo

The motivation is that "required options are generally considered bad form because users expect options to be optional, and thus they should be avoided when possible" as per Argparse docs.

Problem

Although it's a sensible approach that enforces better interfaces in general, in some cases this limitation is very unfortunate.

A real use case: I have a single command script with a few arguments that expect intrinsically very long strings as values (e.g. URLs, digests, etc.). The interface is simple, but the command is completely unreadable. If I want to share the command with args as example or read it in the logs, basically I have to split it line by line and insert comments. It doesn't make sense and the idea of a clean API leads to the worst possible API in practice (in this particular use case).

It would be useful if an argument could be both named and required, just like in Python:

def func(foo, bar):
    ...

# these calls are equivalent:
func(123, 456)
func(foo=123, bar=456)

Argh should not force the developer to always choose whether the argument is required or can be called by name. The following calls should be equivalent:

$ app foo bar
$ app 123 --bar 456
$ app --foo 123 --bar 456

It should however force the developer to do an extra step when making a required argument look like an option to make sure they understand that it's not the norm and that they know what they are doing.

Currently a mix of a positional argument in the function signature (def func(foo):) with an option notation (@arg('--foo')) throws an exception on assembling stage.

Solution

It seems that the usual workaround for this is adding required=True and putting the argument under a special group, see https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments

@neithere neithere changed the title Unable to make a named required argument Unable to pass a required argument by name Apr 15, 2021
@neithere neithere changed the title Unable to pass a required argument by name Passing a required argument by name Apr 15, 2021
@neithere neithere added this to the 1.1 milestone Feb 7, 2023
@neithere
Copy link
Owner Author

This has been made obsolete by #199.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant