Mailman 3 May 2013 - docs

[issue14191] argparse doesn't allow optionals within positionals
by paul j3 06 May '13

06 May '13

paul j3 added the comment: This is the formal patch corresponding to the `test_intermixed.py`. It includes changes to `argparse.rst`, plus tests in `test_argparse.py`. These tests are near the end, after those for `parse_known_args`. They are roughly equivalent to the examples in `test_intermixed.py`. ----------------- The new documentation section is: Some users expect to freely intermix optional and positional argument strings. For example, optparse, by default, allows interspersed argument strings. GNU getopt() permutes the argument strings so non-options are at the end. The parse_intermixed_args() method emulates this behavior by first calling parse_known_args() with just the optional arguments being active. It is then called a second time to parse the list of remaining argument strings using the positional arguments. parse_intermixed_args() raises an error if the parser uses features that are incompatible with this two step parsing. These include subparsers, argparse.REMAINDER, and mutually exclusive groups that include both optionals and positionals. In this example, parse_known_args() returns an unparsed list of arguments [‘2’, ‘3’], while parse_intermixed_args() returns rest=[1, 2, 3]. >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--foo') >>> parser.add_argument('cmd') >>> parser.add_argument('rest', nargs='*', type=int) >>> parser.parse_known_args('cmd1 1 --foo bar 2 3'.split()) (Namespace(cmd='cmd1', foo='bar', rest=[1]), ['2', '3']) >>> parser.parse_intermixed_args('cmd1 1 --foo bar 2 3'.split()) Namespace(cmd='cmd1', foo='bar', rest=[1, 2, 3]) parse_known_intermixed_args() method, returns a two item tuple containing the populated namespace and the list of remaining argument strings. parse_intermixed_args() raises an error if there are any remaining unparsed argument strings. ---------- Added file: http://bugs.python.org/file30160/intermixed.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14191> _______________________________________

1 0

[issue14191] argparse doesn't allow optionals within positionals
by paul j3 06 May '13

06 May '13

paul j3 added the comment: This is a revision of the test_intermixed.py that I submitted earlier. Now `parse_intermixed_args` acts like `parse_args', and calls `parse_known_intermixed_args`. Again it is form that can exercise the idea without modifying `argparse.py`. If the parser has incompatible features (REMAINDER, PARSER, or certain exclusive groups), it raises an error. However to facilitate testing I included a `_fallback` backdoor. If not default None it will be called instead of raising the error. While making documentation changes, I got to wondering whether 'interspersed' would be a better term than 'intermixed'. optparse has an 'interspersed' option and api. However the getopt documentation does use 'intermixed'. ---------- Added file: http://bugs.python.org/file30159/test_intermixed.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14191> _______________________________________

1 0

[issue14187] add "annotation" entry to Glossary
by Chris Rebert 06 May '13

06 May '13

New submission from Chris Rebert <pybugs(a)rebertia.com>: The Glossary should include an entry for "annotation" and/or "function annotation" regarding the language feature introduced by PEP 3107. ---------- assignee: docs@python components: Documentation messages: 154852 nosy: cvrebert, docs@python priority: normal severity: normal status: open title: add "annotation" entry to Glossary versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14187> _______________________________________

8 23

[issue17910] Usage error in multiprocessing documentation
by Andriy Mysyk 06 May '13

06 May '13

New submission from Andriy Mysyk: "As mentioned above, when doing concurrent programming it is usually best to avoid using shared state as far as possible" should say "as much as possible" in multiprocessing.rst. ---------- assignee: docs@python components: Documentation messages: 188461 nosy: amysyk, docs@python priority: normal severity: normal status: open title: Usage error in multiprocessing documentation type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17910> _______________________________________

2 3

urlparse second example wrong output?
by Catalin Patulea 05 May '13

05 May '13

In the second example for urlparse: http://docs.python.org/3.4/library/urllib.parse.html?highlight=urlparse >>> urlparse('www.cwi.nl/%7Eguido/Python.html') ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html', params='', query='', fragment='') I think the "path=" component is wrong. ":80" shouldn't be there. Here is what happens in 2.7: In [2]: urlparse('www.cwi.nl/%7Eguido/Python.html') Out[2]: ParseResult(scheme='', netloc='', path='www.cwi.nl/%7Eguido/Python.html', params='', query='', fragment='')

1 0

Edits to descriptor howto (issue 17894)
by ezio.melotti＠gmail.com 04 May '13

04 May '13

http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst File Doc/howto/descriptor.rst (right): http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:39: with ``a.__dict__['x']``, then ``type(a).__dict__['x']``, and continuing This sentence seems too detailed to me, especially in the "Introduction" http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:43: descriptor methods are defined. This is like the original paragraph Ned suggested, the differences with the original one are: 1) s/The default/Typical/ 2) s/may override the default behavior and/will/ http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:45: Descriptors implements a powerful, general purpose protocol. They are also Here I changed "are a" with "implements". http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:48: new style classes introduced in version 2.2. Descriptors simplify the This sentence could be removed in the 3.x docs. http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:59: .. method:: descr.__get__(self, obj, type=None) -> value Here I added .. method:: and indented the description, to make it more readable. I haven't changed the contents. http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:65: it is passed `None` and the class. The value it returns will be used as This should be ``None``. http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:66: the value of the attribute. This would be better explained with an example IMHO, something like: inst.attr -> attr.__get__(inst, type(inst)) cls.attr -> attr.__get__(None, cls) This should be done for __set__ and __delete__ too. http://bugs.python.org/review/17894/diff/8064/Doc/howto/descriptor.rst#newc… Doc/howto/descriptor.rst:71: It is passed the object and the value to set. I assume that like __get__, if it's called on a class attribute, None and the class are passed instead. http://bugs.python.org/review/17894/

1 0

Different documentation for identical methods (issue 17858)
by ezio.melotti＠gmail.com 04 May '13

04 May '13

http://bugs.python.org/review/17858/diff/8017/Doc/library/threading.rst File Doc/library/threading.rst (right): http://bugs.python.org/review/17858/diff/8017/Doc/library/threading.rst#new… Doc/library/threading.rst:371: necessary waiting until it is released by another thread (only one thread at a These lines are too long. http://bugs.python.org/review/17858/diff/8017/Doc/library/threading.rst#new… Doc/library/threading.rst:377: unconditionally as above. This paragraph could be simplified. "If *blocking* is ``False``, the lock is acquired only if it can be acquired; if it's ``True``, the lock is acquired unconditionally as above." http://bugs.python.org/review/17858/

1 0

[issue17546] Document the circumstances where the locals() dict get updated
by Ezio Melotti 03 May '13

03 May '13

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- nosy: +ncoghlan stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17546> _______________________________________

1 0

Minor bug in ArgumentParser doc?
by Ulf Renman 02 May '13

02 May '13

Hi In section 15.4.2.11 http://docs.python.org/2/library/argparse.html#add-help The last sentance reads "In this case, the first character in prefix_chars is used to prefix the help options:", but that is not what the example code following it shows. I have not tried this code myself, but there is clearly selfcontradiction in the documentation here. /Ulf Renman

1 0

[issue1722] Undocumented urllib functions
by Senthil Kumaran 02 May '13

02 May '13

Senthil Kumaran added the comment: I had added a note in the documentation c3656dca65e7 conveying that splittype, splithost should not be relied upon, and urlparse should be used for parsing. Also, Python3 does not include these in __all__ - It is in Python2 for backwards compatibility purposes. It is not possible provide deprecation warning to things we leave off from __all__ from subsequent versions of python. I consider this request as resolved. Thanks! ---------- resolution: -> fixed status: open -> closed versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1722> _______________________________________

1 0