Mailman 3 April 2022 - Docs-bugs

[issue459007] Document sys.path on Windows
by admin 10 Apr '22

10 Apr '22

Change by admin <roundup-admin(a)psf.upfronthosting.co.za>: ---------- github: None -> 35125 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue459007> _______________________________________

1 0

[issue5901] missing meta-info in documentation pdf
by Ned Deily 08 Apr '22

08 Apr '22

Ned Deily <nad(a)python.org> added the comment: The problem seems to have been fixed again somewhere in the past. ---------- nosy: +ned.deily resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue5901> _______________________________________

1 0

[issue35962] [doc] Slight error in words in [ 2.4.1. String and Bytes literals ]
by Irit Katriel 08 Apr '22

08 Apr '22

Change by Irit Katriel <iritkatriel(a)gmail.com>: ---------- keywords: +easy priority: normal -> low title: Slight error in words in [ 2.4.1. String and Bytes literals ] -> [doc] Slight error in words in [ 2.4.1. String and Bytes literals ] versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35962> _______________________________________

1 0

[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

[issue47255] Many broken :meth: roles in the docs
by Jelle Zijlstra 08 Apr '22

08 Apr '22

New submission from Jelle Zijlstra <jelle.zijlstra(a)gmail.com>: The docs for the hash() builtin use :meth:`__hash__`, but this doesn't actually link to the datamodel documentation for __hash__: it needs :meth:`~object.__hash__` instead. I'm fixing this in the builtin functions docs, but there are probably more places. Why don't we warn when a :meth: link doesn't actually create a link? ---------- assignee: docs@python components: Documentation messages: 416956 nosy: JelleZijlstra, docs@python priority: normal severity: normal status: open title: Many broken :meth: roles in the docs versions: Python 3.10, Python 3.11, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47255> _______________________________________

2 3

[issue47261] RFC: Clarify usage of macros for PySequence_Fast within the Limited C API
by Rohit Goswami 08 Apr '22

08 Apr '22

Change by Rohit Goswami <rog32(a)hi.is>: ---------- title: RFC: Clarify Limited API macros for PySequence_Fast -> RFC: Clarify usage of macros for PySequence_Fast within the Limited C API _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47261> _______________________________________

1 0

[issue47261] RFC: Clarify Limited API macros for PySequence_Fast
by Rohit Goswami 08 Apr '22

08 Apr '22

Rohit Goswami <rog32(a)hi.is> added the comment: Perhaps to be clear, there are two possibilities: 1. `PySequence_Fast` should be removed from the Limited API 2. All macros used with `PySequence_Fast` are valid for use in the context of the Limited API In either case the documentation should need to be clarified. The only situation where no changes would result is if: - `PySequence_Fast` is part of the Limited API, but must be treated the same as a regular `PySequence` object + Since only `PySequence_Size` and other variants can be used in the context of the Limited API This is actually also still confusing and should be mentioned clearly. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47261> _______________________________________

1 0

[issue47261] RFC: Clarify Limited API macros for PySequence_Fast
by Rohit Goswami 08 Apr '22

08 Apr '22

Change by Rohit Goswami <rog32(a)hi.is>: ---------- assignee: -> docs@python components: +C API, Documentation nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47261> _______________________________________

1 0

[issue47138] Bump Sphinx to fix docs build
by Hugo van Kemenade 08 Apr '22

08 Apr '22

New submission from Hugo van Kemenade <hugovk+python(a)gmail.com>: The docs build on GitHub Actions is passing on `main` but has started failing for the `3.7` - `3.10` branches: ``` Missing the required blurb or sphinx-build tools. Please run 'make venv' to install local copies. make[1]: *** [Makefile:50: build] Error 1 ``` https://github.com/python/cpython/actions/workflows/doc.yml https://github.com/python/cpython/runs/5714593700?check_suite_focus=true This is because the `PATH=./venv/bin:$PATH sphinx-build --version` check is failing: ``` /home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/util/docutils.py:45: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. __version_info__ = tuple(LooseVersion(docutils.__version__).version) Traceback (most recent call last): File "/home/runner/work/cpython/cpython/Doc/./venv/bin/sphinx-build", line 5, in <module> from sphinx.cmd.build import main File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/cmd/build.py", line 25, in <module> from sphinx.application import Sphinx File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/application.py", line 42, in <module> from sphinx.registry import SphinxComponentRegistry File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/registry.py", line 24, in <module> from sphinx.builders import Builder File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/builders/__init__.py", line 26, in <module> from sphinx.util import import_object, logging, rst, progress_message, status_iterator File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/util/rst.py", line 22, in <module> from jinja2 import environmentfilter ImportError: cannot import name 'environmentfilter' from 'jinja2' (/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/jinja2/__init__.py) ``` This is because `3.10` and `3.9` are still using old versions of Sphinx (3.2.1 and 2.4.4 respectively) which is incompatible with the newest Jinja2: https://github.com/pallets/jinja/issues/1630 `main` is using a newer Sphinx (4.2.0), so it passes. Bumping to Sphinx 4.5.0 will fix both `3.9` and `3.10`. `3.7` and `3.8` are affected too. We can bump `main` to use `4.5.0` as well. ---------- assignee: docs@python components: Documentation messages: 416149 nosy: docs@python, hugovk priority: normal severity: normal status: open title: Bump Sphinx to fix docs build 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/issue47138> _______________________________________

6 24

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

08 Apr '22

Change by Petr Viktorin <encukou(a)gmail.com>: ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue23312> _______________________________________

1 0

[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

[issue47189] What's new in Python 3.11: Faster CPython
by Ken Jin 06 Apr '22

06 Apr '22

New submission from Ken Jin <kenjin4096(a)gmail.com>: New changeset 9ffe47df5468a72603f730eae48c2fd4ec615ffa by Ken Jin in branch 'main': bpo-47189: What's New in 3.11: Faster CPython (GH-32235) https://github.com/python/cpython/commit/9ffe47df5468a72603f730eae48c2fd4ec… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47189> _______________________________________

1 1

[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

[issue36329] use the right python "make -C Doc/ serve"
by Hugo van Kemenade 06 Apr '22

06 Apr '22

Hugo van Kemenade <hugovk+python(a)gmail.com> added the comment: I've made PRs for this: CPython Docs: https://github.com/python/cpython/pull/32354 Devguide: https://github.com/python/devguide/pull/826 Also set this bpo for Python 3.11. ---------- versions: +Python 3.11 -Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36329> _______________________________________

1 0

[issue36329] use the right python "make -C Doc/ serve"
by Hugo van Kemenade 06 Apr '22

06 Apr '22

Change by Hugo van Kemenade <hugovk+python(a)gmail.com>: ---------- nosy: +hugovk nosy_count: 4.0 -> 5.0 pull_requests: +30406 pull_request: https://github.com/python/cpython/pull/32354 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36329> _______________________________________

1 0

[issue36795] "make venv" failed in Docs
by Hugo van Kemenade 06 Apr '22

06 Apr '22

Hugo van Kemenade <hugovk+python(a)gmail.com> added the comment: I cannot reproduce this (macOS, Python 3.10, pip 22.0.4). As xtreak said, it's probably caused by using a very old version of pip (9.0.1 from Nov 6, 2016), so let's close it. Please let us know if it happens again, and whether updating pip helps. ---------- nosy: +hugovk stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36795> _______________________________________

1 0

[issue30718] [doc] open builtin function: specifying the size of buffer has no effect for text files
by Stanley 06 Apr '22

06 Apr '22

Change by Stanley <ostanley.lee(a)gmail.com>: ---------- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30403 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32351 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30718> _______________________________________

1 0

[issue47121] math.isfinite() can raise exception when called on a number
by Tim Peters 06 Apr '22

06 Apr '22

Tim Peters <tim(a)python.org> added the comment: I'll testify that I won't volunteer one second of my time pursuing these abstract "purity" crusades ;-) `isfinite()` et alia were added to supply functions defined by current standards to work on IEEE floating-point values. People working with floats have reasonable expectations that Python will supply workalikes for industry-stand float functions. If was had to cater to all possible "numberish" types, we'd never add anything new again :-( Doing that in a principled way requires dedicated new dunder methods, and that's a high bar. That I said, I extended math.log() decades ago to work on giant integers. It was useful for real projects I was working on at the time - I was scratching my own itches. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47121> _______________________________________

1 0

[issue47121] math.isfinite() can raise exception when called on a number
by Raymond Hettinger 06 Apr '22

06 Apr '22

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: > isfinite() should return True for all ints, without needing > to coerce them to float Whoa there. You're venturing into changing what those math functions were all about and the core approach to how they operate. A zigzag to this new direction would need discussion with all the math folks. Many tools in the math module are thin wrapper around libmath and we never intended to be universal handlers of all numeric types. We have a lot of functions that start by coercing their input to a float. My two cents is that this would open an endless can of worms and make everyone pay a time and complexity cost for a feature that almost no one needs. AFAICT is more of a purity issue than an actual practical need that would warrant separate code paths (for example, we recently closed an issue where someone wanted math.log() to have a separate code path for Fraction inputs where it return log(f.numerator) - log(f.denominator) with the goal of handling fractional values smaller than float_min). ---------- nosy: +mark.dickinson, tim.peters _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47121> _______________________________________

1 0

[issue47022] PEP 594: Document removal of asynchat, asyncore and smtpd
by Brett Cannon 06 Apr '22

06 Apr '22

Change by Brett Cannon <brett(a)python.org>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47022> _______________________________________

1 0

[issue47121] math.isfinite() can raise exception when called on a number
by Steven D'Aprano 06 Apr '22

06 Apr '22

Steven D'Aprano <steve(a)pearwood.info> added the comment: Isn't this just a quality of implementation issue? math.isfinite should return True for all ints, since all ints are finite. (There are no int infinities or NANs). There is no need to coerce them to float to know that they are finite. Likewise for Fractions. If they overflow, that could be caught and True returned. Decimal infinities convert to float infinities, so the only way you can get an overflow error is if the Decimal is finite but too big to convert. So again, isfinite could (should?) catch the overflow error and return True. Any numeric type that has an infinity which does not coerce to float infinity, but overflows instead, is buggy, and its not isfinite's responsibility to protect against that. So here is my suggestion: isfinite() should return True for all ints, without needing to coerce them to float. For other numeric types, it should try to coerce them to float, and catch OverflowError and raise True. This should be documented, so that other numeric types know what contract they are required to follow (infinity coerces to float infinity). I'm going to change this to an enhancement for 3.11 (or 3.12). ---------- nosy: +steven.daprano type: -> enhancement versions: +Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47121> _______________________________________

1 0

[issue47236] Document types.CodeType.replace() changes about co_exceptiontable
by STINNER Victor 05 Apr '22

05 Apr '22

New submission from STINNER Victor <vstinner(a)python.org>: It would be nice to document the bpo-40222 changes in What's New in Python 3.11 and in the CodeType documentation: * https://docs.python.org/dev/library/types.html#types.CodeType * https://docs.python.org/dev/whatsnew/3.11.html Users of types.CodeType.replace(co_code=new_code) must now pass co_exceptiontable or exception handling will no longer work as expected. Callers are responsible to build co_exceptiontable. Currently, the format of this table is documented at: https://github.com/python/cpython/blob/main/Objects/exception_handling_note… There is no public function to encode this table, it's also the responsibility of the caller. See also bpo-47185 "code.replace(co_code=new_code) no longer catch exceptions on Python 3.11" closed as "won't fix" for the background. ---------- assignee: docs@python components: Documentation messages: 416831 nosy: docs@python, vstinner priority: normal severity: normal status: open title: Document types.CodeType.replace() changes about co_exceptiontable versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47236> _______________________________________

2 1

[issue47184] multiprocessing.set_start_method force argument is not documented
by John Hagen 05 Apr '22

05 Apr '22

New submission from John Hagen <johnthagen(a)gmail.com>: multiprocessing.set_start_method() has a `force` argument that is not documented: https://docs.python.org/3.10/library/multiprocessing.html#multiprocessing.s… ---------- assignee: docs@python components: Documentation messages: 416451 nosy: John Hagen, docs@python priority: normal severity: normal status: open title: multiprocessing.set_start_method force argument is not documented 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/issue47184> _______________________________________

2 2

[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

[issue44158] Clarify documentation for redirected stdout/stderr when using subprocess in Linux
by Stanley 05 Apr '22

05 Apr '22

Stanley <ostanley.lee(a)gmail.com> added the comment: Hmm, I'm not quite following - when you say that the subproccess-ed command should also inherit the redirection, which subprocess command are you referring to, and nested or unnested? I gave it a ran and everything seems to run how I'd expected it, so maybe put another way, what's the expected output from the files and stdout/stderr? ---------- nosy: +slateny _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue44158> _______________________________________

1 0

[issue21956] Doc files deleted from repo are not deleted from docs.python.org.
by Julien Palard 05 Apr '22

05 Apr '22

Julien Palard <julien+python(a)palard.fr> added the comment: This is resolved since https://github.com/python/docsbuild-scripts/pull/28. It could still happen in very specific conditions, but not for a long time, see: https://github.com/python/docs-community/issues/41#issuecomment-1088462199= ---------- nosy: +mdk resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue21956> _______________________________________

1 0

[issue28951] re.flags not documented in Module Contents as promised.
by Irit Katriel 05 Apr '22

05 Apr '22

Change by Irit Katriel <iritkatriel(a)gmail.com>: ---------- keywords: +easy versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue28951> _______________________________________

1 0

[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?
by Paul Ganssle 05 Apr '22

05 Apr '22

New submission from Paul Ganssle <bpo(a)m.ganssle.io>: In bpo-9305, Fred Drake recommends preferring `Returns ...` over the imperative `Return ...`: https://bugs.python.org/issue9305#msg110912 Currently we're pretty consistent about `Return ...`, which is consistent with PEP 257: https://peps.python.org/pep-0257/ That said, I actually think "Returns ..." sounds much better in the documentation, and I'd be happy to see it changed if others agree. I have spun this off from bpo-9305 so that we can unblock https://github.com/python/cpython/pull/31697. ---------- assignee: docs@python components: Documentation messages: 416628 nosy: belopolsky, docs@python, fdrake, p-ganssle, slateny priority: normal severity: normal status: open title: Switch datetime docstrings / documentation to using "Returns" rather than "Return"? versions: Python 3.11 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47207> _______________________________________

2 1

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

05 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

[issue40982] copytree example in shutil
by miss-islington 05 Apr '22

05 Apr '22

miss-islington <mariatta.wijaya+miss-islington(a)gmail.com> added the comment: New changeset bc9ec24290d0fa823fa2ac19ac9767b2b8498faa by Miss Islington (bot) in branch '3.9': bpo-40982: shutil docs: Remove outdated copytree() example (GH-24778) https://github.com/python/cpython/commit/bc9ec24290d0fa823fa2ac19ac9767b2b8… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40982> _______________________________________

1 0

[issue40982] copytree example in shutil
by miss-islington 05 Apr '22

05 Apr '22

miss-islington <mariatta.wijaya+miss-islington(a)gmail.com> added the comment: New changeset 857cf55cbdd65b7a9534dc35d89a19dfe8cbdba5 by Miss Islington (bot) in branch '3.10': bpo-40982: shutil docs: Remove outdated copytree() example (GH-24778) https://github.com/python/cpython/commit/857cf55cbdd65b7a9534dc35d89a19dfe8… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40982> _______________________________________

1 0

[issue32658] Metacharacter (\) documentation suggestion
by miss-islington 05 Apr '22

05 Apr '22

miss-islington <mariatta.wijaya+miss-islington(a)gmail.com> added the comment: New changeset 31c9e35e5360ba91fc6b81b23eb21dd3c39e2257 by Miss Islington (bot) in branch '3.9': bpo-32658: Regex docs: Fix metacharacter reference (GH-32230) https://github.com/python/cpython/commit/31c9e35e5360ba91fc6b81b23eb21dd3c3… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32658> _______________________________________

1 0

[issue32658] Metacharacter (\) documentation suggestion
by miss-islington 05 Apr '22

05 Apr '22

miss-islington <mariatta.wijaya+miss-islington(a)gmail.com> added the comment: New changeset d95e072c419e40b0fb67b8cc8a84087c8a0276ee by Miss Islington (bot) in branch '3.10': bpo-32658: Regex docs: Fix metacharacter reference (GH-32230) https://github.com/python/cpython/commit/d95e072c419e40b0fb67b8cc8a84087c8a… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32658> _______________________________________

1 0

[issue40982] copytree example in shutil
by Jelle Zijlstra 05 Apr '22

05 Apr '22

Jelle Zijlstra <jelle.zijlstra(a)gmail.com> added the comment: Thanks for the report and patch! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40982> _______________________________________

1 0

[issue47007] [doc] str docs are inconsistent with special method lookup
by Vanshaj Singhania 05 Apr '22

05 Apr '22

New submission from Vanshaj Singhania <svanshaj2001(a)gmail.com>: The documentation for the `str` class[^1] says: > If neither encoding nor errors is given, str(object) returns object.__str__() This led our students[^2] to try the following code: >>> class Test: ... def __str__(self): ... return 'hi' ... >>> test = Test() >>> test.__str__ = lambda self: 'bye' >>> str(test) The expected result was calling `test.__str__()`, but instead the interpreter output was `'hi'`. The docs for special method lookup[^3] do say that instance attributes are ignored: > For custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object’s type, not in the object’s instance dictionary. This makes sense, and explains the observed behavior, but the `str` class docs seem to be inconsistent with this. Perhaps it would be more clear if the `str` documentation mentioned that it called `type(object).__str__()` instead of `object.__str__()`. [^1]: https://docs.python.org/3/library/stdtypes.html#str [^2]: CS 61A at UC Berkeley, https://cs61a.org [^3]: https://docs.python.org/3/reference/datamodel.html#special-method-lookup ---------- assignee: docs@python components: Documentation messages: 415110 nosy: docs@python, itsvs priority: normal severity: normal status: open title: [doc] str docs are inconsistent with special method lookup type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue47007> _______________________________________

5 9

[issue40982] copytree example in shutil
by miss-islington 05 Apr '22

05 Apr '22

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- pull_requests: +30386 pull_request: https://github.com/python/cpython/pull/32327 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40982> _______________________________________

1 0

[issue40982] copytree example in shutil
by Jelle Zijlstra 05 Apr '22

05 Apr '22

Jelle Zijlstra <jelle.zijlstra(a)gmail.com> added the comment: New changeset e06f920c5bc6e9fad29082ba0d84043722806e17 by Zackery Spytz in branch 'main': bpo-40982: shutil docs: Remove outdated copytree() example (GH-24778) https://github.com/python/cpython/commit/e06f920c5bc6e9fad29082ba0d84043722… ---------- nosy: +JelleZijlstra _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40982> _______________________________________

1 0

[issue40982] copytree example in shutil
by miss-islington 05 Apr '22

05 Apr '22

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +30385 pull_request: https://github.com/python/cpython/pull/32326 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40982> _______________________________________

1 0

[issue32658] Metacharacter (\) documentation suggestion
by Jelle Zijlstra 05 Apr '22

05 Apr '22

Jelle Zijlstra <jelle.zijlstra(a)gmail.com> added the comment: Thanks for the patch! ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32658> _______________________________________

1 0

[issue32658] Metacharacter (\) documentation suggestion
by miss-islington 05 Apr '22

05 Apr '22

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- pull_requests: +30384 pull_request: https://github.com/python/cpython/pull/32323 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32658> _______________________________________

1 0

[issue32658] Metacharacter (\) documentation suggestion
by Jelle Zijlstra 05 Apr '22

05 Apr '22

Jelle Zijlstra <jelle.zijlstra(a)gmail.com> added the comment: New changeset 43571a3eea8b5931769376daf4bdad1c9184ae0d by Mike cm in branch 'main': bpo-32658: Regex docs: Fix metacharacter reference (GH-32230) https://github.com/python/cpython/commit/43571a3eea8b5931769376daf4bdad1c91… ---------- nosy: +JelleZijlstra _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32658> _______________________________________

1 0