Mailman 3 April 2022 - Docs-bugs

[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