You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.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 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
arg
decorator 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.
The text was updated successfully, but these errors were encountered: