paul j3 added the comment:
Yes, the '_' makes it accessible as an attribute name. But the presence of '-'
in the option name has a UNIX history. That is a flag like '--a-b-c' is
typical, '--a_b_c' is not.
There is less of precedent for a flag like '@@a@b' or '--a@b'.
Here's the relevant code from '_ActionContainer' class.
def _get_optional_kwargs(self, *args, **kwargs):
# determine short and long option strings
...
for option_string in args:
# error on strings that don't start with an appropriate prefix
if not option_string[0] in self.prefix_chars:
...
raise ValueError(msg % args)
# strings starting with two prefix characters are long options
option_strings.append(option_string)
if option_string[0] in self.prefix_chars:
if len(option_string) > 1:
if option_string[1] in self.prefix_chars:
long_option_strings.append(option_string)
# infer destination, '--foo-bar' -> 'foo_bar' and '-x' -> 'x'
dest = kwargs.pop('dest', None)
if dest is None:
if long_option_strings:
dest_option_string = long_option_strings[0]
else:
dest_option_string = option_strings[0]
dest = dest_option_string.lstrip(self.prefix_chars)
if not dest:
msg = _('dest= is required for options like %r')
raise ValueError(msg % option_string)
dest = dest.replace('-', '_')
Even if you need to have odd ball characters in the option flag, you don't have
to settle for them in the 'dest'. You can always give the argument a nice
looking 'dest'.
That's a rather common pattern in 'argparse'. Provide a default handling for
common cases, and provide parameters that let the user override those defaults.
The net effect is to limit the complexity of the code, while increasing the
complexity of the documentation.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24338>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
