Mailman 3 February 2018 - docs

[issue31743] Proportional Width Font on Generated Python Docs PDFs
by Ante Perić May 31, 2020

May 31, 2020

New submission from Ante Perić <synthmeat(a)gmail.com>: Fonts in the generated documentation PDFs, for all Python versions, are proportional width in code blocks, unlike in HTML version, where they are fixed-width. Example https://docs.python.org/2.7/archives/python-2.7.14-docs-pdf-a4.zip ---------- assignee: docs@python components: Documentation files: Screenshot 2017-10-10 12.41.34.png messages: 304024 nosy: docs@python, synthmeat priority: normal severity: normal status: open title: Proportional Width Font on Generated Python Docs PDFs type: enhancement versions: Python 2.7 Added file: https://bugs.python.org/file47203/Screenshot 2017-10-10 12.41.34.png _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31743> _______________________________________

3 2

[issue13649] termios.ICANON is not documented
by anatoly techtonik May 31, 2020

May 31, 2020

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://docs.python.org/library/termios.html is missing documentation for ICANON flag used to put terminal to "raw" mode. It is also worth to place `termios` raw/canonical mode equivalent on `tty` pages, so that people porting C code to Python could understand the hidden magic. ---------- assignee: docs@python components: Documentation, IO, Library (Lib) messages: 150098 nosy: docs@python, techtonik priority: normal severity: normal status: open title: termios.ICANON is not documented versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13649> _______________________________________

3 3

[docs] [issue21889] https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions doesn't explain exception
by Karl Richter May 31, 2020

May 31, 2020

New submission from Karl Richter: Although the section https://docs.python.org/2/library/multiprocessing.html#process-and-exceptio… (of the multiprocessing module documentation) is titled "... and exceptions" it doesn't say anything about exceptions. I assume that it behaves like the thread API (as stated and referenced in the introduction of the module doc). This implies though that either the reference is limited to that statement (-> remove "and exceptions" from the header as there's no special section on them because everything can be found in thread API) or add an explicit reference to the thread API. If this assumption is wrong the section is badly organized or doesn't make any sense at all. I'm not yet sure about exception handling in the multiprocessing module in case it's different from threads, but that shouldn't matter for this doc issue report. I'd also like to suggest a more detailed section on exceptions with usage of queues to pass them as objects to the parent or another process. ---------- assignee: docs@python components: Documentation messages: 221987 nosy: docs@python, krichter priority: normal severity: normal status: open title: https://docs.python.org/2/library/multiprocessing.html#process-and-exceptio… doesn't explain exception type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21889> _______________________________________

4 4

[issue16700] Document that bytes OS API can returns unusable results on Windows
by Serhiy Storchaka May 31, 2020

May 31, 2020

New submission from Serhiy Storchaka: Some OS functions which returns bytes (os.environb, os.getenvb(), os.getcwdb(), os.listdir(), os.readlink(), os.walk(), os.path.abspath(), os.path.expanduser(), os.path.expandvars(), os.path.realpath() and may be other) can return unusable result on Windows (see for example issue13247 and issue16656). The documentation should contains strong warnings about this. ---------- assignee: docs@python components: Documentation, Windows messages: 177613 nosy: docs@python, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Document that bytes OS API can returns unusable results on Windows type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16700> _______________________________________

6 12

[issue29236] 'an ASCII string of one or more PEM-encoded certificates' needs to be unicode
by Maciej Piechorka May 31, 2020

May 31, 2020

New submission from Maciej Piechorka: In documentation it is specified that cadata parameter in load_verify_locations is 'an ASCII string of one or more PEM-encoded certificates'. However the code is actually determining it based on PyUnicode_Check function so the 'ASCII string' actually needs to be unicode object. In Python 3 it seems to be fixed by checking by PyObject_GetBuffer. ---------- assignee: docs@python components: Documentation, SSL messages: 285176 nosy: docs@python, uzytkownik priority: normal severity: normal status: open title: 'an ASCII string of one or more PEM-encoded certificates' needs to be unicode versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29236> _______________________________________

4 3

[issue29257] Possible error in discussion of Abstract Base Classes and abstract properties
by Gerald Britton May 31, 2020

May 31, 2020

New submission from Gerald Britton: I was rereading the 2.7 docs about abstract base classes the other day. I found this: "This defines a read-only property; you can also define a read-write abstract property using the ‘long’ form of property declaration:" along with an example. so I copied the example and put in a little surrounding code: from abc import ABCMeta, abstractproperty class C: __metaclass__ = ABCMeta def getx(self): pass def setx(self, value): pass x = abstractproperty(getx, setx) class D(C): @property def x(self):self._x d = D() print(d) When I ran this, I expected an exception, since I defined a read/write abstract property but only implemented the read operation. However, the example runs fine. That is the class D can be instantiated without error. Of course I cannot set the property since I didn't implement that part. Now, If I don't implement the property at all, I can' instantiate the class. I get: "TypeError: Can't instantiate abstract class D with abstract methods x" which is what I would expect. What I don't understand is why I don't get a similar error when I implement the read operation for the property but not the write operation. If this actually doesn't work (catching the non-implementation at instantiation time), then why is it documented this way? To me at least the doc implies that it *will* raise on the missing write property implementation. If ABCs are working as intended, can the documentation be changed to reflect that as per my experience above? If the documentation is correct, can the ABC implementation be modified to function that way? ---------- assignee: docs@python components: Documentation messages: 285356 nosy: docs@python, gbritton priority: normal severity: normal status: open title: Possible error in discussion of Abstract Base Classes and abstract properties versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29257> _______________________________________

2 1

[issue29323] Wrong documentation (Library) for unicode and str comparison
by RK-5wWm9h May 31, 2020

May 31, 2020

New submission from RK-5wWm9h: PROBLEM (IN BRIEF): In the currently published 2.7.13 The Python Standard Library (Library Reference manual) section 5.6 "Sequence Types" (https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-…): "to compare equal, ... the two sequences must be of the same type" This an *incorrect (and misleading) statement*, for the unicode and str case. PROPOSED FIX: Current full paragraph: "Sequence types also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences must be of the same type and have the same length. (For full details see Comparisons in the language reference.)" Proposed replacement text: "Sequence types also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences must be of the same type and have the same length. (Unicode and str are treated as the same type here; for full details see Comparisons in the language reference.)" DETAILS, JUSTIFICATION, CORRECTNESS, ETC: The current incorrect text is really misleading. The behaviour that a str and a unicode object -- despite being objects of different types -- may compare equal, is explicitly stated in the 2.7.13 The Python Language Reference manual, section 5.9 "Comparisons" (https://docs.python.org/2/reference/expressions.html#comparisons): "* Strings are compared lexicographically using the numeric equivalents (the result of the built-in function ord()) of their characters. Unicode and 8-bit strings are fully interoperable in this behavior. [4]" (Aside: Incidentally an earlier paragraph in the Language Ref fails to cover the unicode and str case; see separately filed bug Issue 29321.) ---------- assignee: docs@python components: Documentation messages: 285792 nosy: RK-5wWm9h, docs@python priority: normal severity: normal status: open title: Wrong documentation (Library) for unicode and str comparison type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29323> _______________________________________

4 5

[issue26433] urllib.urlencode() does not explain how to handle unicode
by Thomas Güttler May 31, 2020

May 31, 2020

New submission from Thomas Güttler: The current docs for Python2, don't explain how to handle unicode: https://docs.python.org/2/library/urllib.html#urllib.urlencode It seems to be a common problem. See http://stackoverflow.com/questions/6480723/urllib-urlencode-doesnt-like-uni… It would be nice to document the most pythonic way to handle unicode in urllib.urlencode() ---------- assignee: docs@python components: Documentation messages: 260845 nosy: Thomas Güttler, docs@python priority: normal severity: normal status: open title: urllib.urlencode() does not explain how to handle unicode versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26433> _______________________________________

2 1

[issue24256] threading.Timer is not a class
by John Runyon May 31, 2020

May 31, 2020

New submission from John Runyon: the documentation (https://docs.python.org/2/library/threading.html#threading.Timer) lists "threading.Timer" as a class. It is not, which means that (for example) you can not use it in isinstance(). "threading._Timer" is a class. "threading.Timer(...).__class__" is a class. "threading.Timer" is a function. >>> import threading >>> threading.Timer <function Timer at 0x7f99cae23848> ---------- assignee: docs@python components: Documentation messages: 243735 nosy: docs@python, jrunyon priority: normal severity: normal status: open title: threading.Timer is not a class versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24256> _______________________________________

5 6

[issue25511] multiprocessing pool blocks SIGTERM from being handled
by David Jones May 31, 2020

May 31, 2020

New submission from David Jones: This is probably related to #21913, but more specifically concerns the documentation. I have a sub process of a larger program that handles a SIGTERM sent by the main process for a clean shutdown. However, if I launch a parallel task in the sub process, via multiprocessing.Pool.imap_unordered, all signals are blocked until pool finishes running the task. If this isn't going to be fixed, then it ought to at least be clearly documented. It took a very long time to diagnose this problem. It requires a programmer to understand the underlying implementation of a high-level construct, thus defeating the purpose of using a high level construct. Also, is there a way to work around this? ---------- assignee: docs@python components: Documentation messages: 253678 nosy: djones, docs@python priority: normal severity: normal status: open title: multiprocessing pool blocks SIGTERM from being handled type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25511> _______________________________________

2 1