Mailman 3 September 2017 - docs

[issue24110] zipfile.ZipFile.write() does not accept bytes arcname
by July Tikhonov Dec. 8, 2020

Dec. 8, 2020

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

[issue25573] traceback documentation example is lying about FrameSummary repr()
by Alexandre Macabies Dec. 8, 2020

Dec. 8, 2020

New submission from Alexandre Macabies: https://docs.python.org/3.5/library/traceback.html#traceback-examples See second code sample and its sample output. According to the docs, the call: print(repr(traceback.extract_tb(exc_traceback))) is supposed to print something that looks like an array with only strings; that is what the doc sample output states: [('<doctest...>', 10, '<module>', 'lumberjack()'), But actually, in 3.5+, this call outputs the repr() of a list of FrameSummary instances that do not go further in repr()esenting their state: [<FrameSummary file <ipython-input-61-3e63d7daea82>, line 10 in <module>>, By looking at the docs I thought I was able to get a nice string representation of a FrameSummary. I actually have to format it myself. It should be reflected in the doc sample output. ---------- assignee: docs@python components: Documentation messages: 254224 nosy: Alexandre Macabies, docs@python priority: normal severity: normal status: open title: traceback documentation example is lying about FrameSummary repr() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25573> _______________________________________

7 16

[issue26582] asyncio documentation links to wrong CancelledError
by awilfox Dec. 4, 2020

Dec. 4, 2020

New submission from awilfox: In the 3.5 and 3.6a0 documentation for asyncio, "CancelledError" is linked to the concurrent.futures.CancelledError. This led me to try catching that exception and finding that it did not work correctly at all. Only after searching for asyncio example code and seeing how other people caught asyncio.CancelledError did I realise the issue. The fact asyncio.CancelledError even exists isn't actually documented, and I believe that is why the :exc: reference is linking to the wrong module. ---------- assignee: docs@python components: Documentation messages: 261911 nosy: awilfox, docs@python priority: normal severity: normal status: open title: asyncio documentation links to wrong CancelledError versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26582> _______________________________________

8 9

[issue15104] abusive language in __name__ description
by anatoly techtonik Dec. 1, 2020

Dec. 1, 2020

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 Dec. 1, 2020

Dec. 1, 2020

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 Nov. 30, 2020

Nov. 30, 2020

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

[issue31189] README.rst: installing multiple versions: typo
by Дилян Палаузов Nov. 26, 2020

Nov. 26, 2020

New submission from Дилян Палаузов: It speaks about pythonX.Y but means python3.${subversion} diff --git a/README.rst b/README.rst --- a/README.rst +++ b/README.rst @@ -190,7 +190,7 @@ script) you must take care that your primary python executable is not overwritten by the installation of a different version. All files and directories installed using ``make altinstall`` contain the major and minor version and can thus live side-by-side. ``make install`` also creates -``${prefix}/bin/python3`` which refers to ``${prefix}/bin/pythonX.Y``. If you +``${prefix}/bin/python3`` which refers to ``${prefix}/bin/python3.X``. If you intend to install multiple versions using the same prefix you must decide which version (if any) is your "primary" version. Install that version using ``make install``. Install all other versions using ``make altinstall``. ---------- assignee: docs@python components: Documentation messages: 300205 nosy: dilyan.palauzov, docs@python priority: normal severity: normal status: open title: README.rst: installing multiple versions: typo versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31189> _______________________________________

2 1

[issue27259] Possible missing deprecation warnings?
by Mark Summerfield Nov. 26, 2020

Nov. 26, 2020

New submission from Mark Summerfield: In the docs for the array module: https://docs.python.org/dev/library/array.html#module-array Note 1 in the table of type codes says that the 'u' type is deprecated and will go in Python 4.0. Since the array.fromunicode() and array.tounicode() methods depend on type code 'u' shouldn't they also be marked as deprecated? If people use the 'u' type code maybe it would be helpful to provide an example of how to store unicode chars in an array.array? (Presumably they'd use type code 'L' and use ord() and chr()?) ---------- assignee: docs@python components: Documentation messages: 267738 nosy: docs@python, mark priority: normal severity: normal status: open title: Possible missing deprecation warnings? type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27259> _______________________________________

2 1

[issue27839] "Python [...] calls sys.displayhook() on unhandled exceptions"
by Jakub Wilk Nov. 25, 2020

Nov. 25, 2020

New submission from Jakub Wilk: <https://docs.python.org/3/library/asyncio-dev.html#detect-exceptions-never-…> reads: "Python usually calls sys.displayhook() on unhandled exceptions. If Future.set_exception() is called, but the exception is never consumed, sys.displayhook() is not called." I believe this should be s/displayhook/excepthook/g. ---------- assignee: docs@python components: Documentation messages: 273446 nosy: docs@python, jwilk priority: normal severity: normal status: open title: "Python [...] calls sys.displayhook() on unhandled exceptions" _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27839> _______________________________________

2 1

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

Nov. 23, 2020

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