-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Historically, in CPython we have functions like _Py_c_sum and _Py_c_prod to do arithmetic with Py_complex
(a custom type for complex numbers). Recent pr python/cpython#124829 added support for mixed-mode arithmetic and this API was extended with functions like _Py_cr_prod (i.e. when one argument is a real number).
It was suggested by @vstinner in python/cpython#124829 (comment) either to remove this from the public API or rename properly (e.g. like Py_complex_add()
and Py_complex_add_real()
, in the GNU GSL style).
With python/cpython#124829 - complex arithmetic in CPython follows to most implementations of the C99+ Annex G. So, users can use native double _Complex
type instead of the Py_complex
. Removing low-level arithmetic API possibly open a door to eventually also switch CPython to use native complex type internally (like for floats).
I see several arguments to keep these functions.
First, not all Tier 1 PEP 11's platforms have Annex G support: it's Windows with MSVC. I don't know if here are some plans to add such support. On another hand, this platform has a different native complex type, _Dcomplex
, with few arithmetic primitives (only multiplication) to do math with.
Second, special arithmetic functions will make sense if we go beyond most Annex G implementations, i.e. add support for pure-imaginary numbers. This was recently suggested: https://discuss.python.org/t/77073/. Probably, we can conclude that this proposal has no enough support.
Third, current Annex G has no special case for real/complex
division. So, current CPython complex arithmetic has a small incompatibility with the standard. This is something, going to be fixed by N3460.
CPython issue: python/cpython#128813