Mailman 3 August 2015 - docs

[issue23522] Misleading note in Statistics module documentation
by Jake 19 Dec '20

19 Dec '20

New submission from Jake: In the statistics module documentation, there is a note that states that "The mean is strongly affected by outliers and is not a robust estimator for central location: the mean is not necessarily a typical example of the data points. For more robust, although less efficient, measures of central location, see median() and mode()" https://docs.python.org/3/library/statistics.html While I appreciate the intention, this is quite misleading. The implication is that the mean, median and mode are different ways to estimate one "central location", however, in reality they are very different things (albeit which refer to a similar notion). The sample mean is an unbiased estimator of the true mean but it need not be unbiased as an estimator of the true median or modes and vice versa for the median and mode. To make this clearer I would rephrase to "The mean is strongly affected by outliers and is not necessarily representative of the central tendency of the data. For cases with large outliers or very low sample size, see median() and mode()" Apologies if this is seen as frivolous, but statistics can be hard enough to remain very clear about even when the words are used precisely. ---------- assignee: docs@python components: Documentation messages: 236612 nosy: Journeyman08, docs@python priority: normal severity: normal status: open title: Misleading note in Statistics module documentation type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23522> _______________________________________

5 11

[issue14586] TypeError: truncate() takes no keyword arguments
by Guy Taylor 15 Dec '20

15 Dec '20

New submission from Guy Taylor <thebigguy.co.uk(a)gmail.com>: The Python docs suggest that io.IOBase.truncate' should take a keyword argument of 'size'. However this causes a 'TypeError': TypeError: truncate() takes no keyword arguments Suggest that the docs are changed to 'truncate(size)' or CPython is changed to allow the keyword. http://docs.python.org/py3k/library/io.html?highlight=truncate#io.IOBase.tr… http://docs.python.org/library/io.html?highlight=truncate#io.IOBase.truncate ---------- assignee: docs@python components: Documentation, Interpreter Core files: test.py messages: 158308 nosy: TheBiggerGuy, docs@python priority: normal severity: normal status: open title: TypeError: truncate() takes no keyword arguments type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25219/test.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14586> _______________________________________

6 15

[issue24110] zipfile.ZipFile.write() does not accept bytes arcname
by July Tikhonov 08 Dec '20

08 Dec '20

New submission from July Tikhonov: In documentation of zipfile.ZipFile.write() there is following notice: "There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write()." I understand it as that 'arcname' argument to write() shouldn't be of type str, but rather bytes. But it is str that works, and bytes that does not: $ ./python Python 3.5.0a4+ (default:6f6e78931875, May 1 2015, 23:18:40) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import zipfile >>> zf = zipfile.ZipFile('foo.zip', 'w') >>> zf.write('python', 'a') >>> zf.write('python', b'b') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/july/source/python/Lib/zipfile.py", line 1442, in write zinfo = ZipInfo(arcname, date_time) File "/home/july/source/python/Lib/zipfile.py", line 322, in __init__ null_byte = filename.find(chr(0)) TypeError: a bytes-like object is required, not 'str' (ZipInfo ostensibly attempts to find a zero byte in the filename, but searches instead for a unicode character chr(0). There are several other places in ZipInfo class that assume filename being str rather than bytes.) I consider this a documentation issue: the notice is misleading. Although maybe there is someone who wants to fix the behavior of ZipInfo to allow bytes filename. ---------- assignee: docs@python components: Documentation messages: 242355 nosy: docs@python, july priority: normal severity: normal status: open title: zipfile.ZipFile.write() does not accept bytes arcname type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24110> _______________________________________

6 9

[issue15104] abusive language in __name__ description
by anatoly techtonik 01 Dec '20

01 Dec '20

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://docs.python.org/library/__main__.html "It is this environment in which the idiomatic “conditional script” stanza causes a script to run" ?!? ---------- assignee: docs@python components: Documentation messages: 163140 nosy: docs@python, techtonik priority: normal severity: normal status: open title: abusive language in __name__ description _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________

12 28

[issue21195] None float format: incomplete documentation
by Eric O. LEBIGOT 01 Dec '20

01 Dec '20

New submission from Eric O. LEBIGOT: The documentation for a None (empty) format for floats indicates that it is equivalent to the g format. This does not appear to be correct (http://stackoverflow.com/questions/16525924/precise-definition-of-float-str…). The Python 3.4 documentation (https://docs.python.org/3.4/library/string.html#format-specification-mini-l…) seems to be much closer to what Python 2.7 does. It would be useful to have a more correct documentation for the effect of a None format for floats in Python 2.7 (maybe by copying the Python 3.4 documentation if it applies). ---------- assignee: docs@python components: Documentation messages: 215871 nosy: docs@python, lebigot priority: normal severity: normal status: open title: None float format: incomplete documentation type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21195> _______________________________________

4 6

[issue13341] Incorrect documentation for "u" PyArg_Parse format unit
by Ilya Novoselov 30 Nov '20

30 Nov '20

New submission from Ilya Novoselov <ilya.novoselov(a)gmail.com>: Documentation states that u format unit returns "buffer of 16-bit Unicode (UTF-16) data" while it returns pointer to internal buffer of unicode data, which is either UCS-16 or UCS-32 http://docs.python.org/c-api/arg.html ---------- assignee: docs@python components: Documentation, Unicode messages: 147002 nosy: Ilya.Novoselov, docs@python, ezio.melotti priority: normal severity: normal status: open title: Incorrect documentation for "u" PyArg_Parse format unit type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13341> _______________________________________

7 9

[issue17576] PyNumber_Index() is not int-subclass friendly
by Barry A. Warsaw 23 Nov '20

23 Nov '20

New submission from Barry A. Warsaw: operator.index() is just a thin wrapper around PyNumber_Index(). The documentation for operator.index() claims that it is equivalent to calling obj.__index__() but for subclasses of int, this is not true. In fact, PyNumber_Index() first does (e.g. in Python 3.3) a PyLong_Check() and if that succeeds, the original object is returned *without* doing the moral equivalent in C of calling obj.__index__(). An example: class myint(int): def __index__(self): return int(self) + 1 >>> x = myint(7) >>> x.__index__() 8 >>> from operator import index >>> index(x) 7 The C API documents PyNumber_Index() as: "Returns the o converted to a Python int on success or NULL with a TypeError exception raised on failure." Because this has been the behavior of PyNumber_Index() since at least 2.7 (I didn't check farther back), this probably cannot be classified as a bug deserving to be fixed in the code for older Pythons. It might be worth fixing for Python 3.4, i.e. by moving the index check before the type check. In the meantime, this is probably a documentation bug. The C API implies, but should be clearer that if o is an int subtype (int and long in Python 2), it is returned unchanged. The operator.index() documentation should be amended to describe this behavior for int/long subclasses. A different alternative would be to leave PyNumber_Index() unchanged, but with the doco fix, and to augment operator.index() to do the PyIndex_Check() first, before calling PyNumber_Index(). That's a little more redundant, but would provide the documented behavior without changing the C API. ---------- assignee: docs@python components: Documentation messages: 185522 nosy: barry, docs@python priority: normal severity: normal status: open title: PyNumber_Index() is not int-subclass friendly type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17576> _______________________________________

14 63

[issue20582] socket.getnameinfo() does not document flags
by Roy Smith 20 Nov '20

20 Nov '20

New submission from Roy Smith: http://docs.python.org/2/library/socket.html The description for getnameinfo() says, "... Depending on the settings of flags, the result can contain a fully-qualified domain name or numeric address representation in host.", but does not say what to pass for flags to get those behaviors. ---------- assignee: docs@python components: Documentation messages: 210838 nosy: docs@python, roysmith priority: normal severity: normal status: open title: socket.getnameinfo() does not document flags versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20582> _______________________________________

9 12

[issue17854] symmetric difference operation applicable to more than two sets
by Amit Saha 18 Nov '20

18 Nov '20

New submission from Amit Saha: The description of the symmetric difference operation implies that it cannot be applied to more than two sets (http://docs.python.org/3/library/stdtypes.html#set.symmetric_difference). However, this is certainly possible: >>> s={1,2} >>> t={2,3} >>> u={3,4} >>> s^t^u {1, 4} >>> s.symmetric_difference(t).symmetric_difference(u) {1, 4} I am not sure how much of a "semantic" sense that makes, given that symmetric difference is by definition for two sets. (http://en.wikipedia.org/wiki/Symmetric_difference). So, either the operator should be fixed to allow only two sets or the description be updated. ---------- assignee: docs@python components: Documentation messages: 187899 nosy: Amit.Saha, docs@python priority: normal severity: normal status: open title: symmetric difference operation applicable to more than two sets type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17854> _______________________________________

6 8

[issue17887] docs: summary page - generator vs iterator vs iterable
by anatoly techtonik 17 Nov '20

17 Nov '20

New submission from anatoly techtonik: Docs lack a good summary page comparing three concepts. The main question is how do I tell if something is a sequence, generator, iterator or iterable? I found myself puzzled that range() is neither generator or iterator. ---------- assignee: docs@python components: Documentation messages: 188203 nosy: docs@python, techtonik priority: normal severity: normal status: open title: docs: summary page - generator vs iterator vs iterable _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17887> _______________________________________

4 4