Mailman 3 November 2012 - docs

[issue16418] argparse with many choices can generate absurdly long usage message
by Chris Jerdonek Nov. 14, 2012

Nov. 14, 2012

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 should be necessary for the user of a command-line script. For example, in Python 2.7 the containers xrange(5, 10), xrange(2, 10, 2), and {1: "foo", 2: "bar"} currently yield the following user-friendly messages for choice 0: invalid choice: 0 (choose from 5, 6, 7, 8, 9) invalid choice: 0 (choose from 2, 4, 6, 8) invalid choice: 0 (choose from 1, 2) With the proposed change, these messages would be as follows, which seem unnecessarily obfuscated: invalid choice: 0 (choose from xrange(5, 10)) invalid choice: 0 (choose from xrange(2, 10, 2)) invalid choice: 0 (choose from {1: 'foo', 2: 'bar'}) Thus, I think the proposal above would be a regression if applied. I think any changes to maintenance releases should preserve the current user-friendly messages (when those messages are user-friendly, e.g. when the containers are small). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

Re: [docs] Backport set and dictionary comprehensions in tutorial to 2.7 (issue 16470)
by fossilet＠users.sourceforge.net Nov. 14, 2012

Nov. 14, 2012

Reviewers: berkerpeksag, ezio.melotti, http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… File Doc/tutorial/datastructures.rst (right): http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:524: {'r', 'd'} I copied all of these from the default branch, not noting the repr is different. But this is my first time cloning the Python source code.. On 2012/11/14 09:23:23, berkerpeksag wrote: > In 2.7.3: > > >>> a = {x for x in 'abracadabra' if x not in 'abc'} > >>> a > set(['r', 'd']) Please review this at http://bugs.python.org/review/16470/ Affected files: Doc/tutorial/datastructures.rst diff -r bb21c800cf49 Doc/tutorial/datastructures.rst --- a/Doc/tutorial/datastructures.rst Mon Nov 12 20:35:29 2012 +0100 +++ b/Doc/tutorial/datastructures.rst Wed Nov 14 14:55:09 2012 +0800 @@ -487,6 +487,10 @@ eliminating duplicate entries. Set objects also support mathematical operations like union, intersection, difference, and symmetric difference. +Curly braces or the :func:`set` function can be used to create sets. Note: To +create an empty set you have to use ``set()``, not ``{}``; the latter creates an +empty dictionary, a data structure that we discuss in the next section. + Here is a brief demonstration:: >>> basket = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana'] @@ -513,6 +517,13 @@ >>> a ^ b # letters in a or b but not both set(['r', 'd', 'b', 'm', 'z', 'l']) +Like :ref:`for lists <tut-listcomps>`, there is a set comprehension syntax:: + + >>> a = {x for x in 'abracadabra' if x not in 'abc'} + >>> a + {'r', 'd'} + + .. _tut-dictionaries: @@ -564,19 +575,18 @@ >>> 'guido' in tel True -The :func:`dict` constructor builds dictionaries directly from lists of -key-value pairs stored as tuples. When the pairs form a pattern, list -comprehensions can compactly specify the key-value list. :: +The :func:`dict` constructor builds dictionaries directly from sequences of +key-value pairs:: >>> dict([('sape', 4139), ('guido', 4127), ('jack', 4098)]) {'sape': 4139, 'jack': 4098, 'guido': 4127} - >>> dict([(x, x**2) for x in (2, 4, 6)]) # use a list comprehension + +In addition, dict comprehensions can be used to create dictionaries from +arbitrary key and value expressions:: + + >>> {x: x**2 for x in (2, 4, 6)} {2: 4, 4: 16, 6: 36} -Later in the tutorial, we will learn about Generator Expressions which are even -better suited for the task of supplying key-values pairs to the :func:`dict` -constructor. - When the keys are simple strings, it is sometimes easier to specify pairs using keyword arguments::

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Chris Jerdonek Nov. 14, 2012

Nov. 14, 2012

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)." ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Chris Jerdonek Nov. 14, 2012

Nov. 14, 2012

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) changes that should be applied only to the in-development branch (i.e. enhancements). I propose that the current issue be used for the former. 3.4-only enhancements can be dealt with as part of a separate issue. I also created issue 16468 for the bug that Terry observed above that ArgumentParser does not in general support "choices" values that support the "in" operator. That issue exists and can be resolved independent of whether the choices collection is large. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

Re: [docs] Backport set and dictionary comprehensions in tutorial to 2.7 (issue 16470)
by ezio.melotti＠gmail.com Nov. 14, 2012

Nov. 14, 2012

If these are documented in the 3.x tutorial, you could backport the changes from there. http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… File Doc/tutorial/datastructures.rst (right): http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:490: Curly braces or the :func:`set` function can be used to create sets. Note: To On 2012/11/14 09:23:23, berkerpeksag wrote: > It would be good to use `.. note::` here. > > See http://sphinx-doc.org/markup/para.html#directive-note Not necessary IMHO. The "note" directive should be used sparingly. http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:520: Like :ref:`for lists <tut-listcomps>`, there is a set comprehension syntax:: The first part of the sentence doesn't sound too good to me. Maybe it could be rephrased to something like "Similarly to list comprehensions, set comprehensions are also supported::" http://bugs.python.org/review/16470/

1 0

Backport set and dictionary comprehensions in tutorial to 2.7 (issue 16470)
by berker.peksag＠gmail.com Nov. 14, 2012

Nov. 14, 2012

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… File Doc/tutorial/datastructures.rst (right): http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:490: Curly braces or the :func:`set` function can be used to create sets. Note: To It would be good to use `.. note::` here. See http://sphinx-doc.org/markup/para.html#directive-note http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:492: empty dictionary, a data structure that we discuss in the next section. s/we/we'll/? http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:524: {'r', 'd'} In 2.7.3: >>> a = {x for x in 'abracadabra' if x not in 'abc'} >>> a set(['r', 'd']) http://bugs.python.org/review/16470/

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Terry J. Reedy Nov. 13, 2012

Nov. 13, 2012

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 that they are now, in effect, special-cased relative to other builtins by having their compact representation replaced by an expanded tuple display. Moreover, the iteration required to do this introduces a discrepancy relative to the doc. This bug might be better fixed by a code change. (The OP did not pass a (x)range object but a list. That was unnecessary and easily fixed in itself. But such a fix leaves the issue above. Condensing long sequences is a somewhat separate issue.) As to intent: "The choices keyword argument may be more convenient for type checkers that simply check against a range of values: >>> >>> parser = argparse.ArgumentParser(prog='PROG') >>> parser.add_argument('foo', type=int, choices=range(5, 10)) >>> parser.parse_args('7'.split()) Namespace(foo=7) >>> parser.parse_args('11'.split()) usage: PROG [-h] {5,6,7,8,9} PROG: error: argument foo: invalid choice: 11 (choose from 5, 6, 7, 8, 9)" Note the expansion instead of the normal representation. It is not a big deal here, but obviously can be. ">>> parser.add_argument( ... 'integers', metavar='int', type=int, choices=range(10), ... nargs='+', help='an integer in the range 0..9')" As to tuple display expansion: the link points to 2284 def _check_value(self, action, value): 2285 # converted value must be one of the choices (if specified) 2286 if action.choices is not None and value not in action.choices: 2287 args = {'value': value, 2288 'choices': ', '.join(map(repr, action.choices))} 2289 msg = _('invalid choice: %(value)r (choose from %(choices)s)') 2290 raise ArgumentError(action, msg % args) In 2288 "', '.join(map(repr, action.choices))" produces a tuple display without parentheses. It essentially reproduced str/repr for tuples, lists, frozensets, sets, dicts, dict views, etc., leaving off the irrelevant fence characters. In doing so, by iteration, it introduces a bug --see below. For range objects, the tuple representation is a drastic change from the normal representation. In that sense, it special cases range among built-ins, and in a bad way when the range represents many values. (Help messages apparently do the same.) I consider this to be something of a bug. So the code as it is would have to special case range objects to avoid special-casing them in the sense above. The same would apply to any custom objects that have a succinct description for a large, possible infinite set. Here are two examples: "a word containing no 'e's" and "a 'word' containing only the letters a, b, c, d, e". Objects representing such infinite sets of strings could easily have a __contains__ method but not an __iter__ method. The code above requires the choices object to be iterable as well as supporting 'in'. This contradicts the doc statement "Any object that supports the in operator can be passed as the choices value,". That discrepancy is a bug. It should be fixed by either adding the restriction to the doc or removing it from the code. I recommend the latter. The code could simply use the str or repr of the choice object without trying to be fancy with a custom, fence-stripped, representation that does not work correctly or at all for all possible choice objects. In other words if action.choices is not None and value not in action.choices: msg = "invalid choice: %r (choose from %r)" % (value, action.choices) raise ArgumentError(action, msg) If the custom representation for non-range builtins is desired, then they are the ones that should be special-cased to not use their default representation. ---------- assignee: docs@python -> keywords: -easy _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Chris Jerdonek Nov. 13, 2012

Nov. 13, 2012

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* operator can be passed as the choices value, so dict objects, set objects, custom containers, etc. are all supported." And here is the code for testing containment: http://hg.python.org/cpython/file/ee7b713fec71/Lib/argparse.py#l2284 Terry, are you okay with the proposed documentation patch? Special-casing the display of range values seems like an enhancement request to me rather than a bug. I would suggest that be handled as an enhancement request targeted initially for Python 3.4. I would be happy to create a new issue for that. Alternatively, it could be considered as a second patch on this issue. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
by Eric Snow Nov. 13, 2012

Nov. 13, 2012

Changes by Eric Snow <ericsnowcurrently(a)gmail.com>: ---------- nosy: +eric.snow _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16194> _______________________________________

1 0

[issue11076] Iterable argparse Namespace
by Eric Snow Nov. 13, 2012

Nov. 13, 2012

Changes by Eric Snow <ericsnowcurrently(a)gmail.com>: ---------- nosy: +eric.snow _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11076> _______________________________________

1 0