Mailman 3 April 2022 - Docs-bugs

[issue23312] google thinks the docs are mobile unfriendly
by Petr Viktorin 08 Apr '22

08 Apr '22

Petr Viktorin <encukou(a)gmail.com> added the comment: This has been solved by the new theme. The Goolgle report linked above shows “Passed” and “96” (out of 100). It does show a few opportunities to improve, but many seem to indirectly complain that the page is big. I'm closing the issue. ---------- nosy: +petr.viktorin _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue23312> _______________________________________

1 0

[issue47121] math.isfinite() can raise exception when called on a number
by Thomas Fischbacher 08 Apr '22

08 Apr '22

Thomas Fischbacher <tfish(a)google.com> added the comment: Tim, the problem may well be simply due to the documentation of math.isfinite() being off here. This is what we currently have: https://docs.python.org/3/library/math.html#math.isfinite === math.isfinite(x) Return True if x is neither an infinity nor a NaN, and False otherwise. (Note that 0.0 is considered finite.) New in version 3.2. === If this were re-worded as follows (and corresponding changes were made to other such functions), everyone would know what the expectations and behavior are: === math.isfinite(x) If `x` is a `float` instance, this evaluates to `True` if `x` is neither a float infinity nor a NaN, and `False` otherwise. If `x` is not a `float` instance, this is evaluates to `math.isfinite(float(x))`. New in version 3.2. === This would be an accurate defining description of the actual behavior. Note that, "thanks to PEP-484", this abbreviation would currently be ambiguous though: === math.isfinite(x) If `x` is a float, this evaluates to `True` if `x` is neither a float infinity nor a NaN, and `False` otherwise. If `x` is not a float, this is evaluates to `math.isfinite(float(x))`. New in version 3.2. === ("ambiguous" since "float" means different things as a static type and as a numbers class - and it is not clear what would be referred to here). Changing/generalizing the behavior might potentially be an interesting other proposal, but I would argue that then one would want to change the behavior of quite a few other functions here as well, and all this should then perhaps go into some other `xmath` (or so) module - bit like it is with `cmath`. However, since the Python philosophy is to not rely on bureaucracy to enforce contracts (as C++, Java, etc. do it), but instead to rely on people's ability to define their own contracts, making the math.isfinite() contract more accurate w.r.t. actual behavior in the CPython implementation via extra clarification looks like a good thing to do, no? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47121> _______________________________________

1 0

[issue20907] behavioral differences between shutil.unpack_archive and ZipFile.extractall
by Semyon 07 Apr '22

07 Apr '22

Change by Semyon <simeon+bpo(a)maryasin.name>: ---------- nosy: +MarSoft _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue20907> _______________________________________

1 0

[issue47252] socket.makefile documentation is missing data regarding the 'buffering' parameter
by Alon Menczer 07 Apr '22

07 Apr '22

New submission from Alon Menczer <alon.menczer(a)gmail.com>: The documentation of the socket.makefile method is missing data regarding the behavior of the `buffering` parameter. ---------- assignee: docs@python components: Documentation messages: 416943 nosy: alon.menczer, docs@python priority: normal severity: normal status: open title: socket.makefile documentation is missing data regarding the 'buffering' parameter type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47252> _______________________________________

1 0

[issue47247] Default arguments for access 'mode' parameters in pathlib and os should display as octal literals
by Aidan Woolley 07 Apr '22

07 Apr '22

New submission from Aidan Woolley <awoolley10(a)gmail.com>: E.g. 0o777 rather than 511 This is a regression since the docs for 3.9 Affected functions/methods: pathlib.Path.mkdir pathlib.Path.touch os.open os.mkdir os.makedirs os.mkfifo os.mknod ---------- assignee: docs@python components: Documentation messages: 416921 nosy: AidanWoolley, docs@python priority: normal severity: normal status: open title: Default arguments for access 'mode' parameters in pathlib and os should display as octal literals type: enhancement versions: Python 3.10, Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47247> _______________________________________

2 1

[issue5901] missing meta-info in documentation pdf
by C.A.M. Gerlach 06 Apr '22

06 Apr '22

Change by C.A.M. Gerlach <CAM.Gerlach(a)Gerlach.CAM>: ---------- keywords: +patch nosy: +CAM-Gerlach nosy_count: 5.0 -> 6.0 pull_requests: +30424 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32386 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue5901> _______________________________________

1 0

[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

[issue47235] Clarify that `assret_called_once_with` sample code is intended typo
by Mariatta 06 Apr '22

06 Apr '22

New submission from Mariatta <mariatta(a)python.org>: In unittest.mock documentation, there is an example code which intentionally contains typo. Source: https://github.com/python/cpython/blame/main/Doc/library/unittest.mock.rst#… We've received quite a number of false "bug report" regarding this text. Basically people saw the sample code containing `assret` then they rushed to create an issue/PR, before actually reading the rest of the section. This typo was intentionally placed there, so it should not be fixed. However since this is definitely confusing to readers, perhaps the documentation should be improved. On Discord, Brandt suggested to add a comment on the sample code like: ``` # Intended typo! ``` so hopefully people will stop trying to fix it. Previous false "bug reports": bpo-35789 bpo-38700 ---------- assignee: docs@python components: Documentation messages: 416826 nosy: Mariatta, docs@python priority: normal severity: normal stage: needs patch status: open title: Clarify that `assret_called_once_with` sample code is intended typo versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47235> _______________________________________

3 8

[issue24778] mailcap.findmatch: document shell command Injection danger in filename parameter
by STINNER Victor 06 Apr '22

06 Apr '22

STINNER Victor <vstinner(a)python.org> added the comment: In 2022, Python 3.11 still has the issue: ---------------- vstinner@apu$ python3.11 -m mailcap Mailcap files: /home/vstinner/.mailcap /etc/mailcap (...) Mailcap entries: (...) text/html copiousoutput lineno 5 view /usr/bin/xdg-open %s $ python3 -m mailcap text/html 'filename; pwd' Executing: /usr/bin/xdg-open filename; pwd (...) /home/vstinner/python/main ---------------- Maybe subst() can be modified to work on a list (as Bernd Dietzel proposed) and then use subprocess to avoid shell and so avoid having to pass a single string, but pass a *list* of arguments (strings). The problem is that it would change the public mailcap.findmatch() API: "Return a 2-tuple; the first element is a string containing the command line to be executed (which can be passed to os.system()), (...)" https://docs.python.org/dev/library/mailcap.html#mailcap.findmatch Adding a new findmatch_list() function avoids the backward compatibility issue, but the existing findmatch() function would remain vulnerable. The other problem is that the mailcap.findmatch() function supports "test" command which executes os.system() on string created by mailcap.subst(). Is the mailcap format (RFC 1524) still used in 2022? Does the mailcap module still belong to the Python stdlib in 2022? I propose to: * (1) Document the shell injection vulnerability: the caller is responsible to validate the filename * (2) Deprecate the mailcap module A code search in the top 5000 PyPI projects (at 2022-01-26) did not find any Python source code using the "mailcap" module. I only found the word "mailcap" used to refer to other things: * https://docs.djangoproject.com/en/4.0/ref/contrib/staticfiles/ mentions a "mailcap" RHEL package: "This can be achieved, for example, by installing or updating the mailcap package on a Red Hat distribution, mime-support on a Debian distribution, or by editing the keys under HKEY_CLASSES_ROOT in the Windows registry." * wxPython refers to "KDE< mailcap and mime.types" https://docs.djangoproject.com/en/4.0/ref/contrib/staticfiles/ ---------- nosy: +vstinner versions: +Python 3.11 -Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue24778> _______________________________________

1 0

[issue47115] Documentation inconsistency with the stable ABI
by Jeremiah Gabriel Pascual 06 Apr '22

06 Apr '22

New submission from Jeremiah Gabriel Pascual <nohackingofkrowten(a)gmail.com>: In https://docs.python.org/3/c-api/typeobj.html#static-types, it says that PyTypeObject isn't part of the stable ABI. Yet, in https://docs.python.org/3/c-api/type.html#c.PyTypeObject, it says that PyTypeObject IS part of the stable ABI. Which is true? ---------- assignee: docs@python components: Documentation messages: 415989 nosy: Crowthebird, docs@python priority: normal severity: normal status: open title: Documentation inconsistency with the stable ABI _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47115> _______________________________________

3 5