@@ -39,6 +39,12 @@ return values are integers." would be accurate. In a similar way we
39
39
can simplify the description of the accepted arguments for functions in both the
40
40
new module and in :external+py3.14:mod: `math `.
41
41
42
+ Now it's a lot harder to satisfy people's expectations about the module
43
+ content. For example, should they expect that ``math.factorial(100) `` will
44
+ return an exact answer? Many languages, Python packages (like :pypi: `scipy `)
45
+ or pocket calculators have functions with same or similar name, that return a
46
+ floating-point value, which is only an approximation in this example.
47
+
42
48
Apparently, the :external+py3.14:mod: `math ` module can't serve as a catch-all place
43
49
for mathematical functions since we also have the :external+py3.14:mod: `cmath ` and
44
50
:external+py3.14:mod: `statistics ` modules. Let's do the same for integer-related
@@ -56,16 +62,26 @@ And this situation tends to get worse. When the module split `was first
56
62
proposed
57
63
<https://mail.python.org/archives/list/[email protected] /thread/YYJ5YJBJNCVXQWK5K3WSVNMPUSV56LOR/> `_,
58
64
there were only two integer-related functions:
59
- :external+py3.14:func: `~math.factorial ` and :external+py3.14:func: `~math.gcd `.
60
- Now there are six and :external+py3.14:func: `~math.factorial ` doesn't accept
65
+ :external+py3.14:func: `~math.factorial ` (accepting also :class: `float `'s, like other
66
+ functions in the module) and :external+py3.14:func: `~math.gcd ` (moved from the
67
+ ::external+py3.14:mod: `fractions ` module). Then
68
+ :external+py3.14:func: `~math.isqrt `, :external+py3.14:func: `~math.comb ` and
69
+ :external+py3.14:func: `~math.perm ` were added, and addition of the new module
70
+ was `proposed second time <https://github.com/python/cpython/issues/81313 >`_,
71
+ so all new functions would go directly to it, without littering the
72
+ :external+py3.14:mod: `math ` namespace.
73
+ Now there are six functions and :external+py3.14:func: `~math.factorial ` doesn't accept
61
74
:class: `float `'s anymore.
62
75
63
76
Some possible additions, among those proposed in the initial discussion thread
64
77
and issue
65
78
`python/cpython#81313 <https://github.com/python/cpython/issues/81313 >`_ are:
66
79
67
- * ``ceil_div() `` --- for integer ceiling divide, see
68
- `relevant discussion thread <https://discuss.python.org/t/91269 >`_.
80
+ * ``c_div() `` and ``n_div() `` --- for integer division with rounding towards
81
+ positive infinity (ceiling divide) and to the nearest integer, see `relevant
82
+ discussion thread <https://discuss.python.org/t/91269> `_. This is reinvented
83
+ several times in the stdlib, e.g. in the :mod: `datetime ` and the
84
+ :mod: `fractions `.
69
85
* ``gcdext() `` --- to solve linear `Diophantine equation <https://en.wikipedia.org/wiki/Diophantine_equation >`_ in two variables (the
70
86
:external+py3.14:class: `int ` implementation actually includes an extended
71
87
Euclidean algorithm)
@@ -110,6 +126,7 @@ module, called ``intmath``:
110
126
* :external+py3.14:func: `~math.perm `
111
127
112
128
Their aliases in :external+py3.14:mod: `math ` will be :term: `soft deprecated `.
129
+ This PEP doesn't introduce backward-incompatible changes.
113
130
114
131
Module functions will accept integers and objects that implement the
115
132
:external+py3.14:meth: `~object.__index__ ` method, which is used to convert the
0 commit comments