This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.j3
Recipients A. Skrobov, docs@python, paul.j3, r.david.murray
Date 2015-10-02.15:54:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1443801300.59.0.437002145254.issue25299@psf.upfronthosting.co.za>
In-reply-to
Content
A related issue is

http://bugs.python.org/issue24754
argparse add_argument with action="store_true", type=bool should not crash

In this case the user specified a parameter that the 'store_true' subclass did not accept.

In both cases, 'parser.add_argument' does minimal error checking (or catching), so the user ends up seeing the '__init__' argument error.

This line in the 'store_const' documentation is clearly wrong.  There's no default.

    (Note that the const keyword argument defaults to the rather
    unhelpful None.)

Possible fixes to the bigger issue:

- major addition to the documentation, documenting allowable subclass parameters (but the subclasses aren't part of the API).

- major addition to add_argument that filters parameters before passing them to the subclasses.  But can that be done without replicating information that is implicit in the subclass __init__?  Can we use advanced inspection?  What about user defined Action classes?

- minor addition to add_argument that catches the __init__ parameter errors and adds a mollifing explanation.

- somehow make Action (and its subclasses) responsible for a nice error message.  But how do you override the normal behavior of Python regarding function parameters?
History
Date User Action Args
2015-10-02 15:55:00paul.j3setrecipients: + paul.j3, r.david.murray, docs@python, A. Skrobov
2015-10-02 15:55:00paul.j3setmessageid: <1443801300.59.0.437002145254.issue25299@psf.upfronthosting.co.za>
2015-10-02 15:55:00paul.j3linkissue25299 messages
2015-10-02 15:54:59paul.j3create