paul j3 added the comment:
In the patch I just posted to http://bugs.python.org/issue16468 I address this
long list issue in several ways:
In the Usage line, the metavar gives the user an alternative
In the expanded help line the user can just omit the '%(choices)s'
In _check_value(), I
Changes by paul j3 ajipa...@gmail.com:
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16418
___
___
Python-bugs-list mailing list
Chris Jerdonek added the comment:
To simplify the discussion and for issue resolution purposes, I propose that
the discussion about large choices containers be divided into separate
discussions for (1) changes that should be applied to all maintenance releases
(i.e. bug fix changes), and (2)
Chris Jerdonek added the comment:
(1) changes that should be applied to all maintenance releases (i.e. bug fix
changes)
This should instead read, (1) changes that should be applied to all
maintenance releases (e.g. bug fix and/or documentation changes).
--
Chris Jerdonek added the comment:
The code could simply use the str or repr of the choice object
It seems to me that this would result in less user-friendly behavior in many
cases. It would also require the end-user to understand Python (e.g. xrange
and dictionaries), which I don't think
R. David Murray added the comment:
I agree with Chris that using the repr in the general case would be a
regression in usability for the end user (and certainly not suitable for a
maintenance release).
Here is some brainstorming:
We could special case this via duck typing. If the object
Chris Jerdonek added the comment:
For maintenance releases, I think I would favor abbreviating the list only if
it is lossless (e.g. for xrange objects). I think I would also be okay with
abbreviating for arbitrary xranges -- in particular for arbitrary steps. For
example, for xrange(0, 50,
Terry J. Reedy added the comment:
I agree that my extreme, strawman-ish, proposal, was, well, too extreme. Here
is a more realistic proposal similar to David's.
if isinstance(choices, range) and len(choices) 50:
choice_txt = range_rep(choices) # details to be determined
try:
choice_txt =
Terry J. Reedy added the comment:
I see that in #16468, Chris proposes that existing versions should let the
TypeError propagate, possibly with an improved error message, and call the use
of repr for non-iterables a new feature (partly on the basis that more fixes
than this are needed to use
Chris Jerdonek added the comment:
Does argparse actually convert (x)range objects to a list or set (the help
indicates the latter) for internal use?
No, it leaves the provided choices argument as is.
Here is what the documentation says argparse accepts: Any object that supports
the *in*
Terry J. Reedy added the comment:
I do not agree with the patch. A summary of my view: Range objects support the
'in' operator and they are an intended option for choices, and, as I said
before, are exactly the right option for arithmetic sequences with more than a
few items. The problem is
Terry J. Reedy added the comment:
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
Juraj Variny added the comment:
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.
Terry J. Reedy added the comment:
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
Chris Jerdonek added the comment:
Proposed documentation patch attached.
--
assignee: - docs@python
components: +Documentation
keywords: +easy, patch
nosy: +docs@python, ezio.melotti
stage: - patch review
type: behavior - enhancement
versions: +Python 3.2, Python 3.3, Python 3.4
Added
New submission from Juraj Variny:
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
R. David Murray added the comment:
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
Chris Jerdonek added the comment:
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.
--
nosy:
Chris Jerdonek added the comment:
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
19 matches
Mail list logo
