paul j3 added the comment:
I'm going to close this. At most it calls for a documentation change. But
saying something like
It must be compatible with argparse._SubParsersAction.
will just confuse the average user. Any customization of this action class is
an advanced topic, that
paul j3 added the comment:
OK, so you are thinking about what happens to the subparsers `dest` when the
user names a command. That isn't handled by the `store` action, but by the
call of the subparsers action
class _SubParsersAction(Action):
def __call__
paul j3 added the comment:
As to the nature of the error when 'add_subparsers' is given an 'action'
parameter:
'add_subparsers' does several things to 'kwargs' before it passes them to the
relevant Action class.
def add_subparsers(self, **kwargs):
# adds 'parser_class'
#
Changes by paul j3 ajipa...@gmail.com:
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23487
___
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +berker.peksag, spaceone
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23487
___
___
SpaceOne added the comment:
In replay to msg238931 from paul j3 (paul.j3) *
And specifying something other than the default 'store' action class for the
arguments of the parsers doesn't make sense.
Of course it makes sense. If you e.g. want the action to be 'append' so that
the
paul j3 added the comment:
It certainly looks like a documentation issue. `action` doesn't make sense
here. `add_subparsers` normally creates an Action of type `_SubParsersAction`.
'action' for normal 'add_argument' command defines the Action type created at
that time. Conceivably a
New submission from BJ Dierkes:
Related: http://bugs.python.org/issue9253
I came across issue9253 in trying to implement a default action for a subparser
namespace. In the absence of a 'default' option, I thought that it may be
possible by adding an 'action' to 'add_subparsers'. Per the
