Mailman 3 February 2022 - Docs-bugs

[issue44213] LIST_TO_TUPLE placed below the sentence "all of the following use their opcodes" in dis library documentaiton.
by glubs9 08 Apr '22

08 Apr '22

New submission from glubs9 <jonte.fry(a)gmail.com>: in the dis library documentation where it lists all of the instructions in python bytecode, it includes a small sentence about half way dow "all of the following instructions use their arguments". After this sentence there is an instruction specified LIST_TO_TUPLE which does not in fact use its argument. It's a minor mistake but 100% on how it should be fixed so I have not yet made a pr. It could be fixed by removing the sentence or just moving it above the sentence. I'm not sure. ---------- assignee: docs@python components: Documentation messages: 394178 nosy: docs@python, glubs9 priority: normal severity: normal status: open title: LIST_TO_TUPLE placed below the sentence "all of the following use their opcodes" in dis library documentaiton. type: enhancement versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue44213> _______________________________________

3 4

[issue46769] Improve documentation for `typing.TypeVar`
by Alex Waygood 06 Apr '22

06 Apr '22

New submission from Alex Waygood <Alex.Waygood(a)Gmail.com>: There are three variants of `TypeVar`s: (1) TypeVars that are neither constrained nor bound: `T = TypeVar("T")` (2) TypeVars that are bound: `U = TypeVar("U", bound=str)` (3) TypeVars that are constrained: `V = TypeVar("V", str, bytes)` The third variant is important for annotating certain functions, such as those in the `re` module. However, it has a number of issues (see https://github.com/python/typing/discussions/1080 for further discussion): (1) It has somewhat surprising semantics in many situations. (2) It is difficult for type checkers to deal with, leading to a number of bugs in mypy, for example. (3) Many users (especially people relatively inexperienced with Python typing) reach for constrained TypeVars in situations where using bound TypeVars or the @overload decorator would be more appropriate. Both PEP 484 and the documentation for the typing module, however: (1) Give examples for variants (1) and (3), but not for variant (2), which is treated as something of an afterthought. (2) Do not mention that TypeVars can be bound to a union of types, which is an important point: `T = TypeVar("T", str, bytes)` has different semantics to `T = TypeVar("T", bound=str|bytes)`, and often the latter is more appropriate. ---------- assignee: docs@python components: Documentation messages: 413342 nosy: AlexWaygood, Jelle Zijlstra, docs@python, gvanrossum, kj, sobolevn priority: normal severity: normal stage: needs patch status: open title: Improve documentation for `typing.TypeVar` type: behavior versions: Python 3.10, Python 3.11, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46769> _______________________________________

5 13

[issue45210] tp_dealloc docs should mention error indicator may be set
by Edward Yang 06 Apr '22

06 Apr '22

New submission from Edward Yang <ezyang(a)mit.edu>: The fact that the error indicator may be set during tp_dealloc is somewhat well known (https://github.com/posborne/dbus-python/blob/fef4bccfc535c6c2819e3f15384600…) but it's not documented in the official manual. We should document it. A simple suggested patch: diff --git a/Doc/c-api/typeobj.rst b/Doc/c-api/typeobj.rst index b17fb22b69..e7c9b13646 100644 --- a/Doc/c-api/typeobj.rst +++ b/Doc/c-api/typeobj.rst @@ -668,6 +668,20 @@ and :c:type:`PyType_Type` effectively act as defaults.) :c:func:`PyObject_GC_Del` if the instance was allocated using :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar`. + If you may call functions that may set the error indicator, you must + use :c:func:`PyErr_Fetch` and :c:func:`PyErr_Restore` to ensure you + don't clobber a preexisting error indicator (the deallocation could + have occurred while processing a different error): + + .. code-block:: c + + static void foo_dealloc(foo_object *self) { + PyObject *et, *ev, *etb; + PyErr_Fetch(&et, &ev, &etb); + ... + PyErr_Restore(et, ev, etb); + } + Finally, if the type is heap allocated (:const:`Py_TPFLAGS_HEAPTYPE`), the deallocator should decrement the reference count for its type object after calling the type deallocator. In order to avoid dangling pointers, the ---------- assignee: docs@python components: Documentation messages: 401854 nosy: docs@python, ezyang priority: normal severity: normal status: open title: tp_dealloc docs should mention error indicator may be set type: enhancement versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45210> _______________________________________

3 4

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example
by David Bereza 05 Apr '22

05 Apr '22

New submission from David Bereza <bokunogf(a)gmail.com>: Documentation link: https://docs.python.org/3/library/logging.config.html#configuration-file-fo… It seems that the example for the "formatter_form01" formatter section specifies following for the style(please note the single-quotes around the value). style='%' This seems to raise a ValueError with the message "Style must be one of..." when parsing the configuration file. Removing the single quotes seems to fix the issue: style=% ---------- assignee: docs@python components: Documentation messages: 409108 nosy: bokunogf, docs@python priority: normal severity: normal status: open title: Incorrect format specified for the "style" key in the configuration file format formatter example versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46168> _______________________________________

4 3

[issue45790] Inaccurate phrasing in extending/newtypes_tutorial
by Rodrigo Tobar 04 Apr '22

04 Apr '22

New submission from Rodrigo Tobar <rtobarc(a)gmail.com>: In `extending/newtypes_tutorial.rst` the following phrase appears: "[...], containing a pointer to a type object and a reference count (these can be accessed using the macros :c:macro:`Py_REFCNT` and c:macro:`Py_TYPE` respectively)." I believe it should read "using the macros :c:macro:`Py_TYPE` and c:macro:`Py_REFCNT` respectively" to follow the same order in which the fields are described. I'll put forward a patch. It seems this phrase goes way back a few python versions, but I'm tagging 3.11 here only. ---------- assignee: docs@python components: Documentation messages: 406185 nosy: docs@python, rtobar2 priority: normal severity: normal status: open title: Inaccurate phrasing in extending/newtypes_tutorial versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45790> _______________________________________

4 7

[issue45317] Document the removal the usage of the C stack in Python to Python calls
by Mark Shannon 04 Apr '22

04 Apr '22

New submission from Mark Shannon <mark(a)hotpy.org>: Assuming that issue 45256 is implemented, we will need to document it. I'm opening a separate issue, so this doesn't get lost in the midst of 45256. We need to: Document the changes to gdb. Possibly at https://wiki.python.org/moin/DebuggingWithGdb, or in the main docs. Add a "what's new" entry explaining what the impact of this change is. ---------- assignee: docs@python components: Documentation messages: 402850 nosy: Mark.Shannon, docs@python priority: release blocker severity: normal status: open title: Document the removal the usage of the C stack in Python to Python calls type: enhancement versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45317> _______________________________________

2 5

[issue46033] Duplicated sentence in for statement documentation
by Michał D 02 Apr '22

02 Apr '22

New submission from Michał D <michcio1234(a)gmail.com>: In for statement description, there seem to be two sentences meant to mean the same: > The suite is then executed once for each item provided by the iterator, in the order returned by the iterator. Each item in turn is assigned to the target list using the standard rules for assignments (see Assignment statements), and then the suite is executed. (from https://docs.python.org/3/reference/compound_stmts.html#the-for-statement) I believe only one of these sentences should be kept (probably the second one). If I am wrong, and the current version is actually correct, then it is unclear - to me it sounds like the iterator is iterated through twice, and suite is executed twice for each item. ---------- assignee: docs@python components: Documentation messages: 408189 nosy: docs@python, michcio1234 priority: normal severity: normal status: open title: Duplicated sentence in for statement documentation versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue46033> _______________________________________

4 6

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not
by jack1142 02 Apr '22

02 Apr '22

New submission from jack1142 <kuba.kuczys(a)gmail.com>: The documentation here: https://docs.python.org/3.10/library/asyncio-task.html#asyncio.Task Says that `loop` parameter was removed but it's still part of the signature. It gets even more confusing when the deprecation right below it is saying that *not* passing it when there is no running event loop is deprecated :) I could make a PR removing this information but I'm not sure whether there should be also some information put about it being deprecated in 3.8 but not actually getting removed in 3.10? ---------- assignee: docs@python components: Documentation messages: 401047 nosy: docs@python, jack1142 priority: normal severity: normal status: open title: asyncio.Task's documentation says that loop arg is removed when it's not type: behavior versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45099> _______________________________________

4 10

[issue45584] Clarifying truncating in documentation
by Arthur Milchior 02 Apr '22

02 Apr '22

New submission from Arthur Milchior <arthur(a)milchior.fr>: While floor/ceil 's documentation are very precise, `truncate` was not explained. I actually had to search online to understand the difference between `truncate` and `floor` (admittedly, once I remembered that numbers are signed, and that floating numbers actually uses a bit for negation symbol instead of two complement, it became obvious) I assume that I won't be the only user having this trouble, especially for people whose mother tongue is not English. So I suggest adding a clarification to help make what should be obvious to most actually explicit ---------- assignee: docs@python components: Documentation messages: 404850 nosy: ArthurMilchior, docs@python priority: normal severity: normal status: open title: Clarifying truncating in documentation type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45584> _______________________________________

5 11

[issue45114] bad example for os.stat
by Harri 02 Apr '22

02 Apr '22

New submission from Harri <harri(a)afaics.de>: The example on https://docs.python.org/3/library/stat.html should be improved to avoid endless recursion, if there is a symlink loop. I would suggest to use os.lstat instead of os.stat. ---------- assignee: docs@python components: Documentation messages: 401133 nosy: docs@python, harridu priority: normal severity: normal status: open title: bad example for os.stat versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45114> _______________________________________

4 7

2023

2022

2021

Docs-bugs February 2022