Option to disable replacement of "_" with "-" in named cli arguments

[pppmlt]

When dispatching a function like the following

def example(*args, this_is_a_long_name): [..] the cli argument will have the "_" replaced with "-".

I would like to have the CLI arguments names (--this_is_a_long_name) to be identical to my function argument names (this_is_a_long_name). Is there any way to achieve this?

[neithere]

Hi @pppmlt, thank you for your interest in Argh!

I'm afraid underscores are not supported in long option names at the moment.

While it's of course possible to implement, I'm not sure if it should be done. The GNU Program Argument Syntax Conventions explicitly recommends the --foo-bar style:

POSIX recommends [...] GNU adds long options to these conventions. Long options consist of -- followed by a name made of alphanumeric characters and dashes. Option names are typically one to three words long, with hyphens to separate words. Users can abbreviate the option names as long as the abbreviations are unique.

The purpose of Argh is to map function signatures to CLI patterns. This means translation between two different worlds and conventions that exist there. That's why we introduce the leading hyphens where you don't have them in Python function arguments, for example. So I think it's reasonable to stick to the GNU convention for argument syntax.

I would close the issue but please feel free to reopen it if you have a valid use case.

[pppmlt]

Thank you for explaining the reasoning behind this. The use-case I had in mind is related to Azure ML and their CLI syntax. To specify inputs/outputs and commands to be run in ML pipelines one can use yaml files. Since the ML use-cases typically run python, the inputs/outputs are passed via CLI arguments. You can find an example here here.

Having to write argparse code for these files is painful and verbose. This is why argh would be useful here. However, if one has to use different names "inside" and "outside" of python seems like its bound to cause mistakes.

I do understand that this might be to much of a niche use-case to be implemented here.

[neithere]

@pppmlt thank you for explanation and example! That's indeed a valid use case, even if a niche one.

I'll take another look at it and see how to make it configurable. It should be probably on app level, not per command, because inconsistency is worse as a source of errors than the need to convert between dashes and underscores.

(Can't promise a quick fix.)