argparse with many choices can generate absurdly long usage message

[JurajVariny]

BPO	16418
Nosy	@terryjreedy, @ezio-melotti, @bitdancer, @cjerdonek
Files	issue-16418-1-default.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2012-11-05.23:11:51.464>
labels = ['type-feature', 'library', 'docs']
title = 'argparse with many choices can generate absurdly long usage message'
updated_at = <Date 2013-07-09.03:13:26.134>
user = 'https://bugs.python.org/JurajVariny'

bugs.python.org fields:

activity = <Date 2013-07-09.03:13:26.134>
actor = 'paul.j3'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'Library (Lib)']
creation = <Date 2012-11-05.23:11:51.464>
creator = 'Juraj.Variny'
dependencies = []
files = ['27946']
hgrepos = []
issue_num = 16418
keywords = ['patch']
message_count = 18.0
messages = ['174947', '174951', '174956', '174957', '175293', '175377', '175386', '175388', '175499', '175520', '175552', '175553', '175555', '175564', '175577', '175582', '175585', '192718']
nosy_count = 8.0
nosy_names = ['terry.reedy', 'bethard', 'ezio.melotti', 'r.david.murray', 'chris.jerdonek', 'docs@python', 'paul.j3', 'Juraj.Variny']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue16418'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

[JurajVariny]

Example:

parser.add_argument("-p","--port", help="Listening port", type=int, choices=range(1, 65535),default=8007,required = False)

generates this usage text:

usage: agent.py [-h]
[-p {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30, <...snip...> ,65522,65523,65524,65525,65526,65527,65528,65529,65530,65531,65532,65533,65534}]

optional arguments:
-h, --help show this help message and exit
-p {1,2,3,4,5,6,7,8,9,10,11,12,13,14, <...snip...> ,65525,65526,65527,65528,65529,65530,65531,65532,65533,65534}
Listening port

[bitdancer]

I don't think choices is a good choice there (pardon the pun). You really want a custom type. I'm inclined to think that that applies to any 'choices' value that is 'too large' for the help display. Part of the point of choices is that you *want* the help display to list all the choices.

I'm inclined to close this as invalid.

[cjerdonek]

I agree with David. Another sign that using "choices" isn't the right approach is that it requires constructing a list of 66,000 elements. There are better ways of checking if a provided argument is an integer between 1 and 65,535.

[cjerdonek]

The argparse documentation says in one part, "The choices keyword argument may be more convenient for type checkers that simply check against a range of values."

Thus, I wouldn't object to language clarifying that choices is meant for lists of choices that should be displayed in the command-line help (e.g. "smaller" lists and human-readable).

[cjerdonek]

Proposed documentation patch attached.

[terryjreedy]

Juraj: Is the example behavior from Py2 or Py3? The meaning of 'range' changed. In Py2, xrange would be the correct choice for 'choice'.

Does argparse actually convert (x)range objects to a list or set (the help indicates the latter) for internal use? That would be foolish as 'n in <range>' is an O(1) operation. (I don't remember is that works for xrange.) For instance, range(0, 1000, 2) is a nice way to say 'even count less than 1000'.

If it is not so converted, converting for display is also foolish.
'range(0, 1000, 2)' is clearer than an explicit sequence.

[JurajVariny]

It was Python 2.7 . But if range shouldn't be used for large number of options, arguing whether it's O(1) is splitting hairs, no?

I'll remove the choices from my code. Adding new type for port is overkill, users should know what legal TCP port numbers are.

[terryjreedy]

I am arguing that (x)range *should* be usable for large numbers of options *because* the containment test is O(1). What happens is you *do* use xrange instead of range in 2.7 or 3.x instead of 2.7?

In 2.x, range(n) *is* a list so that is a bad choice for large n, regardless of the display issue, which could be fixed separately as is being done on other issues.