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 paul.j3, pgacv2
Date 2017-05-02.01:55:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In Steven Bethard includes 'ArgumentTypeError' in a list of values that "look like they should be public but aren't in __all__::".  

I take that `__all__` list to be the ultimate authority on what's public or not, not omissions in the comments or documentation.

ArgumentTypeError is used in an illustration in the 'type' section of the documentation,

It also used in the FileType class, which I see as an example of a custom type callable.

In a function like _get_value it is far easier to test for an custom Error class than to test the message of a more generic class.

The most common `type` functions are `int` and `float`.  Are these custom or generic messages?

    ValueError: invalid literal for int() with base 10: 'one'
    ValueError: could not convert string to float: 'one'

In these common cases the ValueError is converted into a parser.Error call that identifies the argument name, the type, and the bad value, as well as correct usage.

If you issue some other error (e.g. NameError) _get_value won't catch it, and you'll get the full error stack and no 'usage'.  You'd have to wrap the 'parse_args' call in your own try/except block.

I would think than any anticipated error raised by the type callable will be related to the argument's type.  What other errors do you have in mind?  

I did not mean to say in that you shouldn't use it.  The documentation could be better, but it is available.  If it works for you, use it.
Date User Action Args
2017-05-02 01:55:26paul.j3setrecipients: + paul.j3, pgacv2
2017-05-02 01:55:26paul.j3setmessageid: <>
2017-05-02 01:55:26paul.j3linkissue30220 messages
2017-05-02 01:55:25paul.j3create