From 77d8f6472b618b89e78e77442d59aefd02a6e991 Mon Sep 17 00:00:00 2001 From: Sergey B Kirpichev Date: Tue, 5 Aug 2025 18:08:19 +0300 Subject: [PATCH 1/2] PEP 791: address PEP review comments (part 2) * emphasize: no backward-incompatible changes * expand history of the proposal * Motivation: what people should expect about factorial() output? * add n_div() proposal, rename ceil_div() like gmpy2 --- peps/pep-0791.rst | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/peps/pep-0791.rst b/peps/pep-0791.rst index 4d0d449f6bb..a4d7ab8a9e1 100644 --- a/peps/pep-0791.rst +++ b/peps/pep-0791.rst @@ -39,6 +39,13 @@ return values are integers." would be accurate. In a similar way we can simplify the description of the accepted arguments for functions in both the new module and in :external+py3.14:mod:`math`. +Given that currently the module mixes functions for different application +domains, it's a lot harder to satisfy people's expectations about it's content. +For example, should they expect that ``math.factorial(100)`` will return an +exact answer? Many languages (or pocket calculators) have functions with same +or similar name, that return a floating-point value, which is only an +approximation. + Apparently, the :external+py3.14:mod:`math` module can't serve as a catch-all place for mathematical functions since we also have the :external+py3.14:mod:`cmath` and :external+py3.14:mod:`statistics` modules. Let's do the same for integer-related @@ -56,16 +63,26 @@ And this situation tends to get worse. When the module split `was first proposed `_, there were only two integer-related functions: -:external+py3.14:func:`~math.factorial` and :external+py3.14:func:`~math.gcd`. -Now there are six and :external+py3.14:func:`~math.factorial` doesn't accept +:external+py3.14:func:`~math.factorial` (accepting also :class:`float`'s, like other +functions in the module) and :external+py3.14:func:`~math.gcd` (moved from the +::external+py3.14:mod:`fractions` module). Then +:external+py3.14:func:`~math.isqrt`, :external+py3.14:func:`~math.comb` and +:external+py3.14:func:`~math.perm` were added, and addition of the new module +was `proposed second time `_, +so all new functions would go directly to it, without littering the +:external+py3.14:mod:`math` namespace. +Now there are six functions and :external+py3.14:func:`~math.factorial` doesn't accept :class:`float`'s anymore. Some possible additions, among those proposed in the initial discussion thread and issue `python/cpython#81313 `_ are: -* ``ceil_div()`` --- for integer ceiling divide, see - `relevant discussion thread `_. +* ``c_div()`` and ``n_div()`` --- for integer division with rounding towards + positive infinity (ceiling divide) and to the nearest integer, see `relevant + discussion thread `_. This is reinvented + several times in the stdlib, e.g. in the :mod:`datetime` and the + :mod:`fractions`. * ``gcdext()`` --- to solve linear `Diophantine equation `_ in two variables (the :external+py3.14:class:`int` implementation actually includes an extended Euclidean algorithm) @@ -110,6 +127,7 @@ module, called ``intmath``: * :external+py3.14:func:`~math.perm` Their aliases in :external+py3.14:mod:`math` will be :term:`soft deprecated`. +This PEP doesn't introduce backward-incompatible changes. Module functions will accept integers and objects that implement the :external+py3.14:meth:`~object.__index__` method, which is used to convert the From fd1e211420c1d78abd7a5d2e79ab37d9c5765980 Mon Sep 17 00:00:00 2001 From: Sergey B Kirpichev Date: Tue, 5 Aug 2025 19:48:50 +0300 Subject: [PATCH 2/2] + cleanup --- peps/pep-0791.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/peps/pep-0791.rst b/peps/pep-0791.rst index a4d7ab8a9e1..9b1dd749a85 100644 --- a/peps/pep-0791.rst +++ b/peps/pep-0791.rst @@ -39,12 +39,11 @@ return values are integers." would be accurate. In a similar way we can simplify the description of the accepted arguments for functions in both the new module and in :external+py3.14:mod:`math`. -Given that currently the module mixes functions for different application -domains, it's a lot harder to satisfy people's expectations about it's content. -For example, should they expect that ``math.factorial(100)`` will return an -exact answer? Many languages (or pocket calculators) have functions with same -or similar name, that return a floating-point value, which is only an -approximation. +Now it's a lot harder to satisfy people's expectations about the module +content. For example, should they expect that ``math.factorial(100)`` will +return an exact answer? Many languages, Python packages (like :pypi:`scipy`) +or pocket calculators have functions with same or similar name, that return a +floating-point value, which is only an approximation in this example. Apparently, the :external+py3.14:mod:`math` module can't serve as a catch-all place for mathematical functions since we also have the :external+py3.14:mod:`cmath` and