Mailman 3 November 2015 - docs

[issue15457] consistent treatment of generator terminology
by Chris Jerdonek 04 Jan '19

04 Jan '19

New submission from Chris Jerdonek <chris.jerdonek(a)gmail.com>: The documentation on generators (outside of PEP 255) does not currently educate the reader on the more specific "generator function" and "generator iterator" terminology, or at least not in any consistent or systematic way. For example, the glossary includes only a single entry for "generator," and that entry does not mention the two more specific forms. I think it would help for general discourse purposes if this distinction were made clearer, while still continuing to allow for the use of the generic word "generator" when the context makes it clear. There are also cases where index entries can be improved in this regard, and where references to the section containing details about generators can still be added. I am in the process of completing a proposed patch. ---------- assignee: docs@python components: Documentation keywords: easy messages: 166474 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: consistent treatment of generator terminology versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15457> _______________________________________

4 12

[issue18085] Verifying refcounts.dat
by Serhiy Storchaka 20 Dec '18

20 Dec '18

New submission from Serhiy Storchaka: I found one error in Doc/data/refcounts.dat (see issue9369, second argument of PyObject_CallMethodObjArgs is `PyObject*`, not `char*`). Perhaps there are other errors. How this file was generated first? Is it possible to write a tool which will automatically verify at least signatures of functions? ---------- assignee: docs@python components: Documentation messages: 190236 nosy: docs@python, serhiy.storchaka, skip.montanaro priority: normal severity: normal status: open title: Verifying refcounts.dat type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18085> _______________________________________

8 24

[issue9842] Document ... used in recursive repr of containers
by Éric Araujo 20 Nov '18

20 Nov '18

New submission from Éric Araujo <merwok(a)netwok.org>: Built-in containers like dict use an ellipsis to represent a recursive item. In the symbols index, “...” only links to the secondary prompt; I think it should also link to a paragraph explaining the display of recursive containers. ---------- assignee: docs@python components: Documentation keywords: easy messages: 116256 nosy: docs@python, eric.araujo priority: normal severity: normal stage: needs patch status: open title: Document ... used in recursive repr of containers versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9842> _______________________________________

8 17

[issue25438] document what codec PyMemberDef T_STRING decodes the char * as
by Gregory P. Smith 17 Nov '18

17 Nov '18

New submission from Gregory P. Smith: https://docs.python.org/3/c-api/structures.html#c.PyMemberDef T_STRING members are turned into str objects in Python. The documentation needs updating to mention which codec the char * bytes are treated as. Solving this issue involves code inspection and leaving pointers to that code here in the issue, then updating the docs to mention the requirements for the char * member data as well as what happens upon assignment for non-READONLY T_STRING data (a different restriction? or encoding to the same codec?) My _guess_ would be UTF-8 or ASCII but I'll let someone else dive in and find out. This is a Python 3 specific documentation clarification. ---------- assignee: docs@python components: Documentation keywords: easy messages: 253172 nosy: docs@python, gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: document what codec PyMemberDef T_STRING decodes the char * as type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25438> _______________________________________

5 13

[issue21196] Name mangling example in Python tutorial
by Chandan Kumar 20 Oct '18

20 Oct '18

New submission from Chandan Kumar: The example used for demonstrating name mangling could be better if two versions of code are shown - one with name mangling and one without. I have modified the original example to incorporate this (see attached). ---------- assignee: docs@python components: Documentation files: name_mangling_works.py messages: 215872 nosy: chandan, docs@python, rhettinger priority: normal severity: normal status: open title: Name mangling example in Python tutorial type: enhancement Added file: http://bugs.python.org/file34781/name_mangling_works.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21196> _______________________________________

9 18

[issue24568] Misc/NEWS: "free-after-use" -> "use-after-free"
by Jakub Wilk 18 Oct '18

18 Oct '18

New submission from Jakub Wilk: Misc/NEWS reads: "Fix free-after-use bug" It should be "use-after-free", not "free-after-use". ---------- assignee: docs@python components: Documentation messages: 246310 nosy: docs@python, jwilk priority: normal severity: normal status: open title: Misc/NEWS: "free-after-use" -> "use-after-free" versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24568> _______________________________________

5 7

[issue14911] generator.throw() documentation inaccurate
by Kristján Valur Jónsson 18 Oct '18

18 Oct '18

New submission from Kristján Valur Jónsson <kristjan(a)ccpgames.com>: the documentation for generator.throw() does not mention the fact that it has the same semantics for the three arguments as a "raise" expression has. The first two arguments can be: throw(exc_type, None) throw(exc_type, value) throw(exc_type, exc_instance) throw(exc_instance, None) ---------- assignee: docs@python components: Documentation messages: 161565 nosy: docs@python, kristjan.jonsson priority: normal severity: normal status: open title: generator.throw() documentation inaccurate 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/issue14911> _______________________________________

5 12

[issue11233] clarifying Availability: Unix
by Sandro Tosi 16 Oct '18

16 Oct '18

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: Hi, following up http://mail.python.org/pipermail/docs/2011-February/003083.html we have a chat on #python-dev on the topic, the situation is - all started with os.lchmod() and as.lchflags() methods not available on a Debian system - that's because POSIX does not require those functions and then Linux systems don't provide them - so we then thought about clarifying, only for those 2 methods, that they might not be available with a format like "availability: some unix systems" - then we noticed that on top of os doc there's a notice "An “Availability: Unix” note means that this function is commonly found on Unix systems. It does not make any claims about its existence on a specific operating system." and so we thought about linking every 'Availability: Unix' to that note - or transform that not in a footnote and link every 'Availability: Unix' for functions that might not be present to that footnote. It's enough for the conversation dump: ideas/suggestions? :) ---------- assignee: docs@python components: Documentation messages: 128746 nosy: docs@python, sandro.tosi priority: normal severity: normal status: open title: clarifying Availability: Unix _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11233> _______________________________________

11 25

[issue23554] EchoServerClientProtocol class should be called EchoServerProtocol
by Giovanni Cannata 15 Oct '18

15 Oct '18

New submission from Giovanni Cannata: In 18.5.4.3.2. TCP echo server protocol the class in the example code is called EchoServerClientProtocol. It should be EchoServerProtocol. (The client protocol example is correctly called EchoClientProtocol). ---------- assignee: docs@python components: Documentation messages: 236932 nosy: docs@python, gc priority: normal severity: normal status: open title: EchoServerClientProtocol class should be called EchoServerProtocol versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23554> _______________________________________

6 9

[issue24937] Multiple problems in getters & setters in capsulethunk.h
by Petr Viktorin 24 Sep '18

24 Sep '18

New submission from Petr Viktorin: In https://docs.python.org/3/howto/cporting.html#cobject-replaced-with-capsule (added in issue13053): 1) __PyCapsule_GetField is defined as:: #define __PyCapsule_GetField(capsule, field, default_value) ... but called as:: __PyCapsule_GetField(capsule, field) 2) __PyCapsule_SetField returns the wrong value (1 for success, 0 for failure). 3) Both the getter and setter don't set the exception on failure, leading to "SystemError: error return without exception set". Here's a patch. ---------- assignee: docs@python components: Documentation files: capsulethunk.patch keywords: patch messages: 249138 nosy: docs@python, encukou, larry, ncoghlan priority: normal severity: normal status: open title: Multiple problems in getters & setters in capsulethunk.h versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40256/capsulethunk.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24937> _______________________________________

3 11