Mailman 3 February 2014 - docs

[issue9694] argparse required arguments displayed under "optional arguments"
by paul j3 Feb. 13, 2014

Feb. 13, 2014

paul j3 added the comment: The attached file shows how the default argument groups could be redefined, using 'required' as the criteria. I've implemented it as a method that is added to a subclass of ArgumentParser. This method is invoked after arguments are defined, prior to generating the help. The help looks something like this: usage: alt_grouping.py [-h] [-f FOO] -g GOO pos [baz] required: pos required positional -g GOO, --goo GOO required optional optional: -h, --help show this help message and exit -f FOO, --foo FOO optional baz optional positional I was thinking of implementing this as a formatter subclass, but given the way the help is assembled, invoking this method from the parser is simpler. ---------- Added file: http://bugs.python.org/file34065/alt_grouping.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9694> _______________________________________

1 0

[issue9694] argparse required arguments displayed under "optional arguments"
by paul j3 Feb. 13, 2014

Feb. 13, 2014

paul j3 added the comment: As Steven pointed out, the existing `add_argument_group` mechanism can be used to group required arguments. For example ------------------------- temp.py -------------------------- parser = argparse.ArgumentParser(description = 'Do something') group1 = parser.add_argument_group('required arguments') group1.add_argument('--reqarg', '-r', required=True) parser.add_argument('--optarg','-o') parser.add_argument('foo') parser.print_help() ------------------------------------------------------------ usage: ipython [-h] --reqarg REQARG [--optarg OPTARG] foo Do something positional arguments: foo optional arguments: -h, --help show this help message and exit --optarg OPTARG, -o OPTARG required arguments: --reqarg REQARG, -r REQARG Positional 'foo' can also be put in the 'required' group: group1.add_argument('foo') required arguments: --reqarg REQARG, -r REQARG foo The distinction between 'positionals' and 'optionals' (or flagged) is essential to the parsing, but it is not necessary for Help Formatting. I can imagine grouping arguments by 'required/not-required' properties. It might be worth constructing an alternative HelpFormatter class that regroups the arguments in this way. Subclassing the HelpFormatter is the established way of adding features to the help display. The existing HelpFormatter flags 'required' arguments in the usage line with '[]'. There it is has the added task of flagging Mutually Exclusive Groups in the same way. It's worth keeping in mind that whether an argument is 'required' or not is determined in 2 different ways. There is an optional 'required' flag (default False). But this flag is not allowed for 'positionals'. Instead with those 'argparse' looks at 'nargs' ('?*' are not required). The 'required' attribute of an argument (Action) is ignored during 'parse_args' until the end. At that time it makes an inventory of 'required' arguments that have not been seen, and potentially raises an error. That testing was changed in a relatively recent patch, and produced an unintended change in whether 'subparsers' were required or not. (I could look up those issues in needed). I'll think about creating the alternative HelpFormatter. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9694> _______________________________________

1 0

[issue9694] argparse required arguments displayed under "optional arguments"
by Raymond Hettinger Feb. 13, 2014

Feb. 13, 2014

Raymond Hettinger added the comment: > How about calling required arguments "required arguments"? > ... > Clear and unambiguous. With this approach the user does > not have to bloat the help to state "This is required". +1 This is straight-forward, logical, and easy-to-read. ---------- nosy: +rhettinger _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9694> _______________________________________

1 0

[issue19465] selectors: provide a helper to choose a selector using constraints
by Guido van Rossum Feb. 11, 2014

Feb. 11, 2014

Changes by Guido van Rossum <guido(a)python.org>: ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19465> _______________________________________

1 0

[issue19465] selectors: provide a helper to choose a selector using constraints
by STINNER Victor Feb. 11, 2014

Feb. 11, 2014

STINNER Victor added the comment: It looks you rejected my idea, so I'm in favor of just closing the issue. Do you agree? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19465> _______________________________________

1 0

Google search results for Python docs have misleading titles
by Andrew Gorcester Feb. 10, 2014

Feb. 10, 2014

Hello, Sorry for filing this bug by email, but I think it is an issue with the Python documentation production webserver configuration and not anything in the repo. I may be wrong, but hopefully someone on this list can help me sort it out. For the last several months, at least, there has been a problem where using Google to search for Python documentation, for instance "python unittest", brings up a result that shows e.g. "Unittest - Python 3.3.3 documentation" as the title of the page. However, clicking through brings the user to the Python 2.7.x documentation. Users unfamiliar with the different layouts of the two documentation versions may not realize that this has happened and be mislead to thinking they are actually on the 3.3 documentation page. https://www.google.com/search?q=python+unittest This applies to other modules and even applies if the user searches for e.g. "python 2.7 unittest". A search query for "python 3.3 unittest" works as expected. Strangely, this does not affect Duck Duck Go or Bing, both of which correctly identify the page as Python 2.7 documentation. I was unable to determine why this has happened via my cursory inspection of the generated source for the documentation page, so I'm afraid I don't have any more specific information. Thank you, Andrew Gorcester

1 0

[issue19871] json module won't parse a float that starts with a decimal point
by Terry J. Reedy Feb. 10, 2014

Feb. 10, 2014

Terry J. Reedy added the comment: To me, the JSONDecoder doc at the top of this section http://docs.python.org/3/library/json.html#encoders-and-decoders is unclear about decoding process and timing of application and the signature of all 5 hook functions. The timing and signature issues are related. My questions and suggestions: - 'Simple JSON decoder.' + 'A simple JSON decoder that splits JSON strings into JSON substrings that represent programming objects and then converts the substrings into Python objects.' I took the above from Mark's description, using 'substring' instead of 'token'. - '\nPerforms the following translations in decoding by default:' + 'The default translations from JSON object strings to Python objects are as follows:' Should the table have multiple notes? The intended use case for JSON is program to program communication, where both programs 'understand' the legal JSON syntax. Is handcrafting JSON strings, without knowing the syntax, also an intended usecase? I think not. Teaching the syntax is out of scope for the docs. However, the table could be followed by a generic note that JSON syntax and Python syntax for objects are different. + "The legal JSON syntax for various classes is different from Python syntax for the same classes. The tranformations above are only applied to legal JSON strings. For instance, both float('.5') and float(0.5) are legal Python code, but a JSON encoder will only produce '0.5', so a JSON decoder will reject '.5' as an error and not pass it on to float() or its parse_float substitute." This suggestion is intended to replace class by class notes or the proposed addition to the parse_float entry. I think the description of the parse hooks would be clearer if the input signature were given immediately with the name. object_hook: I do not understand enough to suggest anything. Is the input a json string representing an object or a Python dict? object_pairs_hook: Ditto. What is its input? parse_int: This should come before parse_float, to match the table. - '*parse_int*, if specified ...' + '*parse_int*(*num_str*), if specified ...' 'num_str' as the parameter name is used in the ... part. parse_float(num_str): ditto parse_constant(const_str): I do not understand "This can be used to raise an exception if invalid JSON numbers are encountered." >>> def f(s): raise ValueError('custom') ... >>> json.loads('.5', parse_constant=f) gives same error as as without parse_constant. The sentence should be rewritten or removed. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19871> _______________________________________

2 1

[issue19871] json module won't parse a float that starts with a decimal point
by Terry J. Reedy Feb. 10, 2014

Feb. 10, 2014

Terry J. Reedy added the comment: > My point is that Python and JSON are two different languages which have different syntaxes. That is also the point of the generic note I suggested, which explains the consequence of the difference (rejection by JSON parser before calling Python constructor), with just one example given. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19871> _______________________________________

1 0

[issue9694] argparse required arguments displayed under "optional arguments"
by Terry J. Reedy Feb. 10, 2014

Feb. 10, 2014

Changes by Terry J. Reedy <tjreedy(a)udel.edu>: ---------- versions: -Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9694> _______________________________________

1 0

[issue19871] json module won't parse a float that starts with a decimal point
by Serhiy Storchaka Feb. 10, 2014

Feb. 10, 2014

Serhiy Storchaka added the comment: My point is that Python and JSON are two different languages which have different syntaxes. JSON is not Python and Python is not JSON. We can't enumerate all differences unless to cite Python [1] and JSON [2] specifications. For differences from JSON specifications see [3]. [1] http://docs.python.org/3/reference/index.html [2] http://tools.ietf.org/html/rfc4627.html [3] http://docs.python.org/3/library/json.html#standard-compliance ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19871> _______________________________________

1 0