Mailman 3 August 2014 - docs

[issue13211] urllib2.HTTPError does not have 'reason' attribute.
by Jason R. Coombs Oct. 4, 2014

Oct. 4, 2014

New submission from Jason R. Coombs <jaraco(a)jaraco.com>: The urllib2 docs indicate that HTTPError is a subclass of URLError and that URLError has an attribute of 'reason', but HTTPError does not have this attribute. The docs should be updated to reflect this deviance. It appears the Python 3.2 docs no longer include documentation for URLError Python 2.7.2 >>> try:urllib2.urlopen('http://api.wordnik.com/v4/word.json/foo/examples') ... except urllib2.HTTPError as exc: ... print(dir(exc)) ... ['_HTTPError__super_init', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__getitem__', '__getslice__', '__hash__', '__init__', '__iter__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__', '__subclasshook__', '__unicode__', '__weakref__', 'args', 'close', 'code', 'errno', 'filename', 'fileno', 'fp', 'getcode', 'geturl', 'hdrs', 'headers', 'info', 'message', 'msg', 'next', 'read', 'readline', 'readlines', 'strerror', 'url'] The same issue exists in Python 3.2.2. Here's what I propose: - For Python 3.2 and 3.3, update HTTPError to supply a @property, aliasing .msg (will .msg always be a suitable .reason?). - For Python 2.7, document the deviance, such as by adding the following wording to the HTTPError docs: "Unlike URLError, HTTPError does not supply a reason attribute. The reason can be retrieved through the msg attribute." ---------- assignee: docs@python components: Documentation messages: 145805 nosy: docs@python, jason.coombs priority: normal severity: normal status: open title: urllib2.HTTPError does not have 'reason' attribute. versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13211> _______________________________________

8 23

[issue19472] inspect.getsource() raises a wrong exception type
by Marco Buttu Oct. 3, 2014

Oct. 3, 2014

New submission from Marco Buttu: I was looking at inspect.getsource(). In Python 3.3 and 3.4 either the docstring and the online doc say it raises a OSError, and in fact: >>> import inspect >>> def foo(): ... pass ... >>> inspect.getsource(foo) Traceback (most recent call last): ... OSError: could not get source code However, getsource() calls getfile(), and this one raises a TypeError: >>> inspect.getsource(0) Traceback (most recent call last): ... TypeError: 0 is not a module, class, method, function, traceback, frame, or code object ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 201891 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: inspect.getsource() raises a wrong exception type type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19472> _______________________________________

3 3

[issue18729] In unittest.TestLoader.discover doc select the name of load_tests function
by py.user Oct. 2, 2014

Oct. 2, 2014

New submission from py.user: http://docs.python.org/3/library/unittest.html#unittest.TestLoader.discover "If load_tests exists then discovery does not recurse into the package" ---------- assignee: docs@python components: Documentation files: issue.diff keywords: patch messages: 195092 nosy: docs@python, py.user priority: normal severity: normal status: open title: In unittest.TestLoader.discover doc select the name of load_tests function type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file31283/issue.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18729> _______________________________________

4 3

[issue19434] Wrong documentation of MIMENonMultipart class
by Vajrasky Kok Oct. 2, 2014

Oct. 2, 2014

New submission from Vajrasky Kok: >>> from email.mime.nonmultipart import MIMENonMultipart >>> MIMENonMultipart.__doc__ 'Base class for MIME multipart/* type messages.' >>> Attached the patch to fix the doc of MIMENonMultipart class. ---------- assignee: docs@python components: Documentation files: fix_doc_for_mime_non_multipart.patch keywords: patch messages: 201643 nosy: docs@python, r.david.murray, vajrasky priority: normal severity: normal status: open title: Wrong documentation of MIMENonMultipart class versions: Python 3.4 Added file: http://bugs.python.org/file32410/fix_doc_for_mime_non_multipart.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19434> _______________________________________

3 3

[issue19342] Improve grp module docstrings
by Marius Gedminas Oct. 2, 2014

Oct. 2, 2014

New submission from Marius Gedminas: This patch gives grp.getgrnam and grp.getgrgid sligtly more useful docstrings, and brings them in line with pwd.getpwnam/pwd.getpwuid. Compare pydoc pwd.getpwnam: pwd.getpwnam = getpwnam(...) getpwnam(name) -> (pw_name,pw_passwd,pw_uid, pw_gid,pw_gecos,pw_dir,pw_shell) Return the password database entry for the given user name. See help(pwd) for more on password database entries. After looking at it I know that I can convert a name to an UID by doing pwd.getpwnam(name).pw_uid. Meanwhile pydoc grp.getgrnam: grp.getgrnam = getgrnam(...) getgrnam(name) -> tuple Return the group database entry for the given group name. If name is not valid, raise KeyError. is rather unfriendly and makes me reach for Google just so that I could find out the names of the namedtuple members. ---------- assignee: docs@python components: Documentation files: grpmodule-docstrings.patch keywords: patch messages: 200896 nosy: docs@python, mgedmin priority: normal severity: normal status: open title: Improve grp module docstrings type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file32295/grpmodule-docstrings.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19342> _______________________________________

4 4

[issue19622] Default buffering for input and output pipes in subprocess module
by Martin Panter Oct. 2, 2014

Oct. 2, 2014

New submission from Martin Panter: Currently the documentation for the “bufsize” parameter in the “subprocess” module says: """ Changed in version 3.2.4,: 3.3.1 bufsize now defaults to -1 to enable buffering by default to match the behavior that most code expects. In 3.2.0 through 3.2.3 and 3.3.0 it incorrectly defaulted to 0 which was unbuffered and allowed short reads. This was unintentional and did not match the behavior of Python 2 as most code expected. """ First of all the formatting is a bit screwy. There’s a colon in the wrong place, so it’s not obvious that the “changed in version” heading applies to the following paragraph. The main issue is that I got the impression the default of 0 was a regression, and that Python 3.1 and Python 2 defaulted to -1. However, as far as I can tell the default was actually 0 in 3.1 and 2. The change to -1 was for Issue 17488, which seems to be focussed on the behaviour of reading from a subprocess’s output pipe. In Python 2, file.read() blocks to read as much as possible, even when buffering is disabled. In Python 3, you end up with either a FileIO or a BufferedIOBase object, and they have different read() behaviours. Perhaps the documentation should say something like """ The “bufsize” argument now defaults to -1 to enable buffering. In 3.2.3, 3.3.0, and earlier, it defaulted to 0 which was unbuffered and allowed short reads. """ I would take out the “most code expects buffering” bits. Maybe most code expects the greedy read behaviour from output pipes, but I would say most code writing to an input pipe expects unbuffered behaviour. The big issue with buffering for me is that BufferedWriter.close() may raise a broken pipe condition. If you want to mention Python 2, maybe say that Python 2 did not use buffering by default, but that file.read() always had blocking read behaviour, which can be emulated by using buffered reading in Python 3. ---------- assignee: docs@python components: Documentation messages: 203010 nosy: docs@python, vadmium priority: normal severity: normal status: open title: Default buffering for input and output pipes in subprocess module type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19622> _______________________________________

4 5

[issue21739] Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
by Karl Richter Oct. 1, 2014

Oct. 1, 2014

New submission from Karl Richter: It would be useful to have a short statement in the docs (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) that the expression in a list comprehension isn't put into a block, but evaluated against the same block where it is located because intuitively one might think that variables can be overridden in the statement. This applies to both 2.7 and 3.4.1. ---------- assignee: docs@python components: Documentation messages: 220374 nosy: docs@python, krichter priority: normal severity: normal status: open title: Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21739> _______________________________________

6 9

[issue16252] bytes and bytearray methods are undocumented
by Antoine Pitrou Sept. 27, 2014

Sept. 27, 2014

New submission from Antoine Pitrou: Everything is in the title. I couldn't find any doc for bytes.join, etc. (while str methods are documented in library/stdtypes.html#string-methods). ---------- assignee: docs@python components: Documentation messages: 173074 nosy: docs@python, pitrou priority: normal severity: normal stage: needs patch status: open title: bytes and bytearray methods are undocumented type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16252> _______________________________________

5 6

[issue10702] bytes and bytearray methods are not documented
by Alexander Belopolsky Sept. 27, 2014

Sept. 27, 2014

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: Library reference manual has a section dedicated to string methods [1], but similar methods of bytes and bytearray types are not documented. Adding two new sections would probably be too repetitious, so I wonder if it would make sense to add notes about byte/bytearray methods to the matching string methods' entries. See also issue10587. [1] http://docs.python.org/dev/py3k/library/stdtypes.html#string-methods ---------- assignee: docs@python components: Documentation messages: 123960 nosy: belopolsky, docs@python priority: normal severity: normal status: open title: bytes and bytearray methods are not documented versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10702> _______________________________________

6 7

[issue20974] email module docs say not compatible with current python version
by Jim Jewett Sept. 27, 2014

Sept. 27, 2014

New submission from Jim Jewett: http://docs.python.org/3.4/library/email.html#package-history The table ends with email version 5.1, distributed with Python 3.2, and compatible with Python 3.0 to 3.2. Since Python 3.3 and 3.4 also distribute 5.1.0, I'm betting that the actual compatibility is at least 3.0-3.4. (Currently, it is also used on the 3.5 tip, but I suppose we don't want to guarantee that yet.) ---------- assignee: docs@python components: Documentation, email keywords: easy messages: 214018 nosy: Jim.Jewett, barry, docs@python, r.david.murray priority: normal severity: normal status: open title: email module docs say not compatible with current python version versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20974> _______________________________________

4 6