Mailman 3 November 2021 - Docs-bugs

[issue44544] Add full list of possible args to textwrap: wrap, fill, shorten
by Andrei Kulakov March 19, 2022

March 19, 2022

New submission from Andrei Kulakov <andrei.avk(a)gmail.com>: https://docs.python.org/3.11/library/textwrap.html The 3 functions - wrap, fill, shorten -- have a signature like `(..., **kwargs)`, where kwargs are instance attrs of TextWrap. It would be better to list all possible args in the signature because: - more convenient for users rather than scrolling back and forth between description of the function and the list under TextWrap - the list under TextWrap is so long it doesn't fit on one screen. It would be great to have a compact list in the signature of these 3 functions - it's confusing -- at first sight, it seems like **kwargs will be taken in to be used by a subclass or maybe stored as attrs on the instance and not used, and it seems like arbitrary kwargs can be given. - the only reason it was done so, I guess, is that the list is long and unwieldy. But that's also the reason why the listing under TextWrap takes up more than a screenful and so more of an argument to have a compact list in the signature. - in case of fill, some args are a no-op, so they can be omitted from the signature, that will make it much easier to see all effective arguments. ---------- assignee: docs@python components: Documentation messages: 396817 nosy: andrei.avk, docs@python priority: normal severity: normal status: open title: Add full list of possible args to textwrap: wrap, fill, shorten type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue44544> _______________________________________

5 15

[issue45680] Documentation on `GenericAlias` objects could be improved
by Alex Waygood March 8, 2022

March 8, 2022

New submission from Alex Waygood <Alex.Waygood(a)Gmail.com>: The documentation on `GenericAlias` objects implies at multiple points that only container classes can implement `__class_getitem__`, and goes into very little detail about what it means for a non-container class to be parameterized. ---------- assignee: docs@python components: Documentation messages: 405384 nosy: AlexWaygood, docs@python, gvanrossum, kj, lukasz.langa priority: normal severity: normal status: open title: Documentation on `GenericAlias` objects could be improved type: behavior versions: Python 3.10, Python 3.11, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45680> _______________________________________

5 39

[issue45492] stdlib inspect documentation on code.co_names is incorrect
by Dutcho March 2, 2022

March 2, 2022

New submission from Dutcho <dutcho(a)ziggo.nl>: The standard library documentation on module inspect starts with an overview of types and attributes. This overview (in all Python versions) states: code.co_names: tuple of names of local variables code.co_varnames: tuple of names of arguments and local variables That suggests the argument names are set(code.co_varnames) - set(code.co_names), which is incorrect. I think the attribute description should be: code.co_names: tuple of names of used global and built-in variables >>> def f(x): a = 1; print(f, a) >>> assert f.__code__.co_varnames == ('x', 'a') # argument and local, in that order >>> assert set(f.__code__.co_names) == set(('f', 'print')) # global and built-in (don't care order), not local ---------- assignee: docs@python components: Documentation messages: 404068 nosy: Dutcho, docs@python priority: normal severity: normal status: open title: stdlib inspect documentation on code.co_names is incorrect 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/issue45492> _______________________________________

3 6

[issue45735] Promise that the long-time truth that `args=list` works
by Tim Peters Feb. 26, 2022

Feb. 26, 2022

New submission from Tim Peters <tim(a)python.org>: A number of contexts allow specifying a tuple of arguments to be passed later to a function. The Thread constructor is a fine example, and happened to come up (again! for me) here today: https://stackoverflow.com/questions/69858950/why-do-we-have-to-add-comma-in… This often confuses especially newbies, because the function they intend to parallelize often takes only a single argument, and Python's syntax for a 1-element tuple actually _requires_ parentheses in the context of an argument list, with a naked trailing comma: t = threading.Thread(target=access, args=(thread_number,)) It "looks weird" to people. I'm not suggesting to change that, but instead to officially bless the workaround I've seen very often in real code: use a list instead. t = threading.Thread(target=access, args=[thread_number]) Nobody scratches their head over what that means. CPython's implementations typically couldn't care less what kind of sequence is used, and none that I'm aware of verify that it's specifically a tuple. The implementations just go on to do some simple variation of self.target(*self.args) Tuple or list makes no real difference. I'm not really keen to immortalize the "any sequence type whatsoever that just happens to work" implementation behavior, but am keen to promise that a list specifically will work. A lot of code already relies on it. ---------- assignee: docs@python components: Documentation keywords: easy messages: 405846 nosy: docs@python, tim.peters priority: low severity: normal stage: needs patch status: open title: Promise that the long-time truth that `args=list` works type: behavior versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45735> _______________________________________

5 11

[issue45393] help() on operator precedence has confusing entries "avait" "x" and "not" "x"
by Max Feb. 10, 2022

Feb. 10, 2022

New submission from Max <mh+bugs.python.org(a)dsi972.fr>: Nobody seems to have noticed this AFAICS: If you type, e.g., help('+') to get help on operator precedence, the fist column gives a lit of operators for each row corresponding to a given precedence. However, the row for "not" (and similar for "await"), has the entry "not" "x" That looks as if there were two operators, "not" and "x". But the letter x is just an argument to the operator, so it should be: "not x" exactly as for "+x" and "-x" and "~x" and "x[index]" and "x.attribute", where also x is not part of the operator but an argument. On the corresponding web page https://docs.python.org/3/reference/expressions.html#operator-summary it is displayed correctly, there are no quotes. ---------- assignee: docs@python components: Documentation messages: 403321 nosy: MFH, docs@python priority: normal severity: normal status: open title: help() on operator precedence has confusing entries "avait" "x" and "not" "x" 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/issue45393> _______________________________________

5 8

[issue45380] help() appears confused about the module of typing.Annotated
by Alex Waygood Feb. 3, 2022

Feb. 3, 2022

New submission from Alex Waygood <Alex.Waygood(a)Gmail.com>: `help()` appears confused about the module of `typing.Annotated`. If you call `help()` on a parameterised "instance" of `typing.Annotated`, it will claim that `Annotated` belongs to whatever module the annotated type is from. Additionally, `help()` appears not to know about the `__metadata__` attribute of `typing.Annotated`. ``` >>> from typing import Annotated, Callable >>> t = Annotated[int | str, "Some metadata"] >>> help(t) Help on _AnnotatedAlias in module types: Annotated = int | str >>> u = Annotated[Callable[[int], str], "Some metadata"] >>> help(u) Help on _AnnotatedAlias in module typing: Annotated = typing.Callable[[int], str] >>> s = Annotated[int, "Some metadata"] Help on _AnnotatedAlias in module builtins: Annotated = class int(object) | int([x]) -> integer | int(x, base=10) -> integer # (etc., giving the entire output of help() for `int`) ``` ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 403258 nosy: AlexWaygood, docs@python priority: normal severity: normal status: open title: help() appears confused about the module of typing.Annotated type: behavior versions: Python 3.10, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45380> _______________________________________

3 4

[issue45298] SIGSEGV when access a fork Event in a spawn Process
by Keming Jan. 23, 2022

Jan. 23, 2022

New submission from Keming <kemingy94(a)gmail.com>: Code to trigger this problem: ```python import multiprocessing as mp from time import sleep def wait_for_event(event): while not event.is_set(): sleep(0.1) def trigger_segment_fault(): event = mp.get_context("fork").Event() p = mp.get_context("spawn").Process(target=wait_for_event, args=(event,)) p.start() # this will show the exitcode=-SIGSEGV sleep(1) print(p) event.set() p.terminate() if __name__ == "__main__": trigger_segment_fault() ``` Accessing this forked event in a spawned process will result in a segment fault. I have found a related report: https://bugs.python.org/issue43832. But I think it's not well documented in the Python 3 multiprocessing doc. Will it be better to explicit indicate that the event is related to the start method context in the documentation? ---------- assignee: docs@python components: Documentation messages: 402687 nosy: docs@python, kemingy priority: normal severity: normal status: open title: SIGSEGV when access a fork Event in a spawn Process type: crash _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45298> _______________________________________

2 1

[issue45877] Inconsistency in minimal supported version of Microsoft Visual Studio
by Oleg Iarygin Jan. 21, 2022

Jan. 21, 2022

New submission from Oleg Iarygin <oleg(a)arhadthedev.net>: According to PCbuild/readme.txt: > Using this directory requires an installation of > Microsoft Visual Studio 2017 (MSVC 14.1) of any edition. However, Doc/using/windows.rst states that Visual Studio 2017 is not required and 2015 may be used instead: > The source tree contains a build solution and project files for Microsoft > Visual Studio 2015, which is the compiler used to build the official Python > releases. VS 2017 mention was introduced in GH-3418. So either PCbuild readme needs to relax its requirements back or windows.rst needs to be updated. ---------- assignee: docs@python components: Build, Documentation messages: 406826 nosy: arhadthedev, docs@python, steve.dower priority: normal severity: normal status: open title: Inconsistency in minimal supported version of Microsoft Visual Studio type: behavior 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/issue45877> _______________________________________

2 2

[issue45554] multiprocessing exitcode is insufficiently documented
by John Marshall Jan. 18, 2022

Jan. 18, 2022

New submission from John Marshall <jmarshall(a)hey.com>: <https://docs.python.org/3.11/library/multiprocessing.html#multiprocessing.P…> describes exitcode as "The child’s exit code. This will be None if the process has not yet terminated. A negative value -N indicates that the child was terminated by signal N." and similarly in earlier documentation versions. This does not describe what the exit code will be under normal circumstances, or if the child abends by raising a Python exception. By examination of BaseProcess._bootstrap() it can be determined that the current behaviour appears to be: * even if your subclass overrides the run() method, whatever this method returns is ignored (and in particular the return value has no effect on the child's exit code); * if the run() method returns normally, the child's exit code will be 0; * if the run() method raises SystemExit (or, I guess, calls sys.exit()) with an integer exit status, that exit status will be propagated to the child's exit code; * if the run() method raises any other exception, the exception traceback will be printed to stderr and the child's exit code will be 1. However I did not see a way to figure these details out from the documentation, and it is unclear whether all these details are supported behaviours. ---------- assignee: docs@python components: Documentation messages: 404597 nosy: docs@python, jmarshall priority: normal severity: normal status: open title: multiprocessing exitcode is insufficiently documented type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45554> _______________________________________

5 11

[issue37800] Clean up the documentation on module attributes
by miss-islington Jan. 16, 2022

Jan. 16, 2022

New submission from miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: New changeset d7e210070f915d8df5fa863ecba8628304ee1ded by Géry Ogam in branch 'main': bpo-37800: Clean up importlib documentation for some module attributes (GH-10016) https://github.com/python/cpython/commit/d7e210070f915d8df5fa863ecba8628304… ---------- nosy: +miss-islington _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37800> _______________________________________

2 1