There doesn't appear to be a way to have an argument with the same name as a keyword, and it may also be undesirable to shadow a builtin. For example, if you were implementing a Git command:
you would get a SyntaxError on not, and you'd have to use builtins.all explicitly in the body of the function. It seems from the operator module that the conventional way to avoid this problem is to append an underscore (as in operator.not_).
Describe the solution you'd like
I'd suggest trimming a trailing underscore from the declared names of arguments (name = name.removesuffix("_")) prior to processing. Readability would only be minimally affected:
It seems very unlikely that someone would want to create a command-line option with a trailing dash, but it could still be accomplished by adding a second underscore.
Describe alternatives you've considered
The arg decorator could accept an argname= parameter to allow for arbitrary naming of command arguments, but that seemed to provide too much of an opportunity to harm readability, and it would probably be more complicated to implement.
Additional context
The solution to this may or may not be related to #220, since both involve alternative ways to name arguments.
Is your feature request related to a problem?
There doesn't appear to be a way to have an argument with the same name as a keyword, and it may also be undesirable to shadow a builtin. For example, if you were implementing a Git command:
you would get a SyntaxError on
not, and you'd have to usebuiltins.allexplicitly in the body of the function. It seems from the operator module that the conventional way to avoid this problem is to append an underscore (as inoperator.not_).Describe the solution you'd like
I'd suggest trimming a trailing underscore from the declared names of arguments (
name = name.removesuffix("_")) prior to processing. Readability would only be minimally affected:It seems very unlikely that someone would want to create a command-line option with a trailing dash, but it could still be accomplished by adding a second underscore.
Describe alternatives you've considered
The
argdecorator could accept anargname=parameter to allow for arbitrary naming of command arguments, but that seemed to provide too much of an opportunity to harm readability, and it would probably be more complicated to implement.Additional context
The solution to this may or may not be related to #220, since both involve alternative ways to name arguments.