paul j3 <ajipa...@gmail.com> added the comment:
When I run your setup in ipython, I see a display of the newly added Action:
Out[2]: _StoreAction(option_strings=['--a-b', '--ab'], dest='a_b',
nargs=None, const=None, default=None, type=None, choices=None, help=None,
metavar=None)
Note the 'option_strings' list.
This strings are also entered as keys in a parser dictionary:
In [6]: list(ap._option_string_actions.keys())
Out[6]: ['--a-b', '--help', '--ab', '-h']
The values are the corresponding Actions, in this case the default 'help' one,
and the newly added 'StoreAction'. So the parser can only tell if two keys are
'aliases' by checking for matching values.
The abbreviation ambiguity error is raised in 'parser._parse_optional'. If
'ap.allow_abbrev' is does
ap._get_option_tuples('--a')
and raises the error if this returns more than one Action. It does not check
whether the multiple actions has the same ID. I suppose it could, but it
doesn't.
The option string is passed to the Action.__call__:
def __call__(self, parser, namespace, values, option_string=None):
setattr(namespace, self.dest, values)
None of the defined Action subclasses makes use of the this 'option_string'
parameter (that I recall). But I can easily imagine writing a custom Action
class that does make use of this parameter.
Are aliases like this needed? Seems they just clutter the help:
usage: ipython3 [-h] [--a-b A_B]
optional arguments:
-h, --help show this help message and exit
--a-b A_B, --ab A_B
The clutter will be more obvious with longer realistic flags.
Here the aliases end up disabling the '--a' abbreviation. '--a-' still works.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32833>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
