paul j3 added the comment:
Those strings are defined in a 'parser.registry' dictionary, with expressions
like
self.register('action', 'store', _StoreAction)
(Users can also register their own custom classes. The registry can also be
used for the 'type' attribute.)
So you can already do:
parser.add_argument('--foo', action=argparse._StoreAction)
So I don't think we need another mapping like
argparse.STORE_ACTION = argparse._StoreAction
I think these Action subclasses are not part of the API because users should
never instantiate one directly. It should always be done via the
'add_argument' method.
But on occasion it is handy to grab one of the Action objects when it is
returned by add_argument, and display or even modify one of its attributes.
Some users are reluctant to do so because that's not documented.
Some of the `nargs` values have constants names in addition to the string
values.
argparse.REMAINDER = '...'
argparse.OPTIONAL = '?'
so on for '+', '*', and even '+...'. Users almost always use the strings,
while the code always uses the constant.
But because `argparse._StoreAction` is a class, with its own defined methods,
there's never a need to test for its 'value' or identity. So the code does not
need a `argparse.STORE_ACTION flag.
So for end users, and for internal code use, the current use of subclasses and
the registry is works, and doesn't need to be changed just to look more like
other modules.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29632>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
