cmath.log has an invalid signature #89381

mdickinson · 2021-09-16T09:09:01Z

BPO	45218
Nosy	@mdickinson, @vstinner, @corona10

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-09-16.09:09:00.708>
labels = ['extension-modules', 'type-bug', '3.9', '3.10', '3.11']
title = 'cmath.log has an invalid signature'
updated_at = <Date 2021-09-24.15:55:05.789>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2021-09-24.15:55:05.789>
actor = 'corona10'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2021-09-16.09:09:00.708>
creator = 'mark.dickinson'
dependencies = []
files = []
hgrepos = []
issue_num = 45218
keywords = []
message_count = 5.0
messages = ['401933', '401937', '401938', '401939', '401940']
nosy_count = 3.0
nosy_names = ['mark.dickinson', 'vstinner', 'corona10']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45218'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

Linked PRs

mdickinson · 2021-09-16T09:09:01Z

inspect.signature reports that the cmath.log function has an invalid signature:

Python 3.11.0a0 (heads/fix-44954:d0ea569eb5, Aug 19 2021, 14:59:04) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> import inspect
>>> inspect.signature(cmath.log)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 3215, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2963, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2432, in _signature_from_callable
    return _signature_from_builtin(sigcls, obj,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2244, in _signature_from_builtin
    return _signature_fromstr(cls, func, s, skip_bound_arg)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2114, in _signature_fromstr
    raise ValueError("{!r} builtin has invalid signature".format(obj))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: <built-in function log> builtin has invalid signature

mdickinson · 2021-09-16T11:45:41Z

Issue bpo-43067 is similar. I'm not sure what the best solution is in this case:

un-argument-clinic cmath.log, and document the signature using two lines (similar to range):

     log(z)
     log(z, base)

change the behaviour of cmath.log so that the second argument is allowed be None (and defaults to None)

mdickinson · 2021-09-16T12:12:30Z

See also bpo-36306 and bpo-29299. There may be nothing to be done here, but it would be nice if math.log and cmath.log at least behaved in the same way. A default of None doesn't seem like a terrible option.

(BTW, just to forestall the suggestion, a default of math.e or cmath.e is definitely not the right thing to use as a default: math.e is not exactly Euler's value for e, and log base math.e is likely to be less accurate than plain natural log.)

mdickinson · 2021-09-16T12:35:38Z

and log base math.e is likely to be less accurate than plain natural log

Nope, that's nonsense, since the two-argument form simply divides by log(base), and while log(math.e) is mathematically not exactly 1 (its exact value, assuming IEEE 754 binary64, starts 0.9999999999999999468176229339410862948..., which is off from 1.0 by around 0.48 ulps), it's *just* close enough that with a well-behaved libm log implementation it's exactly 1.0 after rounding.

I still don't like the idea of math.e as a default value here, but I'd have to work harder to identify why it makes me uneasy.

vstinner · 2021-09-16T12:50:52Z

The current Argument Clinic syntax for math.log() is:

--------------
/*[clinic input]
math.log

x:    object
[
base: object(c_default="NULL") = math.e
]
/

Return the logarithm of x to the given base.
(...)
--------------

math.log.__text_signature__ is None. __text_signature__ is used by inspect.signature().

I guess that it's a bug in Argument Clinic.

skirpichev · 2023-01-16T08:18:58Z

The underlying reason of failure for this issue is that the math.e (default value) is neither in the module dict (i.e. cmath) nor in the sys_module_dict. (Hence wrap_value() in the inspect module fails.) I don't see a clear solution here.

#101070 implements a workaround with base=None defaults (both for math and cmath), as it was suggested above (I hope) by @mdickinson.

hauntsaninja · 2023-01-18T00:45:06Z

I'm not sure the failure is to do with module dict.

Like Victor mentions, I think there's some bug or missing feature in Argument Clinic. If you manually modify the generated file to:

diff --git a/Modules/clinic/mathmodule.c.h b/Modules/clinic/mathmodule.c.h
index 9fac1037e5..4c463a49b0 100644
--- a/Modules/clinic/mathmodule.c.h
+++ b/Modules/clinic/mathmodule.c.h
@@ -187,7 +187,7 @@ exit:
 }
 
 PyDoc_STRVAR(math_log__doc__,
-"log(x, [base=math.e])\n"
+"log(x, base=math.e)\n--\n\n"
 "Return the logarithm of x to the given base.\n"
 "\n"
 "If the base not specified, returns the natural logarithm (base e) of x.");

Then __text_signature__ and inspect.signature do the right thing.

Edit: what skirpichev says is true of cmath, but not for math. For cmath we can just use cmath.e

hauntsaninja · 2023-01-18T00:47:44Z

Actually, looking at it again, why do we need the optional group in mathmodule.c at all? Maybe I'm missing something simple, but removing the optional group should just make all the signature stuff work. I'll open a PR and you can tell me what I'm missing...

The optional group in math.log seems unnecessary, as far as I can tell. Once we remove this, Argument Clinic knows what to do. For cmath, we just do what math is doing, which is use c_default = NULL (so the actual runtime logic is unchanged), but mark cmath.e as the fake default value.

skirpichev · 2023-01-18T05:50:58Z

After some debugging, it seems that the mentioned by @vstinner math.log issue is not a Clinic's bug, rather a feature. Here is a comment from the clinic.py:

# docstring_only means "don't generate a machine-readable
# signature, just a normal docstring".  it's True for
# functions with optional groups because we can't represent
# those accurately with inspect.Signature in 3.4.

Correct me, but it's not something that is planned to be in the Signature someday, right? Some searching suggests me that there are instead plans to convert such cases to arg=default notation (see this).

hauntsaninja · 2023-01-18T06:02:16Z

Yes, that's correct. The thing that was confusing for me here is that an optional group is seemingly unnecessary for math.log — so when I posted my first comment I didn't even realise there was one!
See e.g. curses.window.addch for an example of something that can't be represented accurately with an inspect.Signature https://docs.python.org/3/library/curses.html#curses.window.addch

skirpichev · 2023-01-19T07:29:18Z

BTW, it seems the broken signature is not a bug for stdlib. See #101123.

fochoao · 2023-01-19T12:20:05Z

cmath.log has an invalid signature.

fochoao · 2023-01-19T12:31:39Z

5282f4f indeed, solved.

rhettinger · 2023-01-29T22:01:47Z

log(x, base=None, /)
    Return the logarithm of x to the given base.

    If the base is not specified or is None, returns the natural
    logarithm (base e) of x.

FWIW, I object to these changes. They are changing the user experience negatively. It is incorrect to say these were "invalid". The functions predated signature objects. They aren't broken; rather, they are like the range() function in that signatures have not yet grown the ability the express what they do (in contrast, type annotations support overloads and have no problem with these functions).

In Python 3.11, the doc entry read log(x, [base=math.e]) which was succinct helpful and correct. Now, the "signature" has changed. The log function never took a None argument — it stayed firmly in the world of floats as does it C counterpart. Now, the help and tooltips are less useful. Nothing about log(x, base=None) communicates that a natural log is the default.

I haven't done a new speed measurement but presumably having to check for None before calling the float conversion is more expensive than just directly converting to a float when a second argument is present. This is problematic in fine grained functions like log that are supposed to be short, fast, and suitable for use in a loop.

AFAICT, no actual user problem is being solved. No one have ever reported a usability issue here. Instead, the focus seems to be on shoe-horning functions into the argument clinic and signature arguments. When they two don't match (as in this case), there seems to be willingness to damage the function rather than on improving the capabilities of signature objects.

Summary: I don't think log should take None as a argument. AFAICT no other math tool or other programming language does this. It is a strictly float/complex argument. We really don't want to allow or encourage users to write log(x, None). That is a usability regression. Likewise, the new tooltip and doc entry are less usable. While people are all about everything having a signature object might be made happier, actual users of math.log are worse off.

This is permanent, forever API change. I don't think we have to live with the likes of log(12.34, None) in perpetuity.

rhettinger · 2023-01-29T22:03:57Z

I've attached a screenshot of what the tooltips now look like in IDLE. Note, there is no mention of a natural logarithm being the default.

I would like to see these changes reverted.

hauntsaninja · 2023-01-29T23:59:27Z

@rhettinger Apologies if I merged it too quickly!

I'm curious if you feel the other PR is useful: #101115
That PR has no effect on the implementation of math.log or cmath.log, other than simplifying the generated argument parsing code for math.log (edit: which should result in improved perf).

re: showing the base explicitly, @mdickinson expressed some concern about about implying that math.log(x) is equivalent to math.log(x, math.e) in #101115 (comment) and above.

skirpichev · 2023-01-30T00:20:24Z

About benchmarks.

On the main (666c084):

$ ./python -m timeit -s 'from math import log' -s 'n = 10' \
    -s 'a = [1.1 for _ in range(n)]' '[log(_) for _ in a]'
50000 loops, best of 5: 5.17 usec per loop
$ ./python -m timeit -s 'from math import log' -s 'n = 100' \
    -s 'a = [1.1 for _ in range(n)]' '[log(_) for _ in a]'
5000 loops, best of 5: 41.9 usec per loop
$ ./python -m timeit -s 'from math import log' -s 'n = 1000' \
    -s 'a = [1.1 for _ in range(n)]' '[log(_) for _ in a]'
1000 loops, best of 5: 400 usec per loop
$ ./python -m timeit -s 'from cmath import log' -s 'n = 10' \
    -s 'a = [1.1 + 1.2j for _ in range(n)]' '[log(_) for _ in a]'
50000 loops, best of 5: 5.25 usec per loop
$ ./python -m timeit -s 'from cmath import log' -s 'n = 100' \
    -s 'a = [1.1 + 1.2j for _ in range(n)]' '[log(_) for _ in a]'
5000 loops, best of 5: 41.8 usec per loop
$ ./python -m timeit -s 'from cmath import log' -s 'n = 1000' \
    -s 'a = [1.1 + 1.2j for _ in range(n)]' '[log(_) for _ in a]'
1000 loops, best of 5: 387 usec per loop

On the branch (was rebased wrt main):

$ ./python -m timeit -s 'from math import log' -s 'n = 10' \
    -s 'a = [1.1 for _ in range(n)]' '[log(_) for _ in a]'
100000 loops, best of 5: 2.85 usec per loop
$ ./python -m timeit -s 'from math import log' -s 'n = 100' \
    -s 'a = [1.1 for _ in range(n)]' '[log(_) for _ in a]'
10000 loops, best of 5: 21.1 usec per loop
$ ./python -m timeit -s 'from math import log' -s 'n = 1000' \
    -s 'a = [1.1 for _ in range(n)]' '[log(_) for _ in a]'
2000 loops, best of 5: 196 usec per loop
$ ./python -m timeit -s 'from cmath import log' -s 'n = 10' \
    -s 'a = [1.1 + 1.2j for _ in range(n)]' '[log(_) for _ in a]'
50000 loops, best of 5: 5.29 usec per loop
$ ./python -m timeit -s 'from cmath import log' -s 'n = 100' \
    -s 'a = [1.1 + 1.2j for _ in range(n)]' '[log(_) for _ in a]'
5000 loops, best of 5: 41.9 usec per loop
$ ./python -m timeit -s 'from cmath import log' -s 'n = 1000' \
    -s 'a = [1.1 + 1.2j for _ in range(n)]' '[log(_) for _ in a]'
1000 loops, best of 5: 389 usec per loop

Indeed, there is slight speed regression for the cmath.log. But for the math.log, there is a speed gain...

rather than on improving the capabilities of signature objects.

@rhettinger, that you would like here, as I guess, is the #101115, but with a symbolic constant in the signature/help instead, correct?

Actually, this might work like this (same for the math module):

diff --git a/Modules/cmathmodule.c b/Modules/cmathmodule.c
index 2038ac26e6..861a824d77 100644
--- a/Modules/cmathmodule.c
+++ b/Modules/cmathmodule.c
@@ -952,7 +952,7 @@ cmath_tanh_impl(PyObject *module, Py_complex z)
 cmath.log
 
     z as x: Py_complex
-    base as y_obj: object = NULL
+    base as y_obj: object(c_default="NULL") = e
     /
 
 log(z[, base]) -> the logarithm of z to the given base.

With that change we have:

>>> import cmath
>>> cmath.log.__text_signature__
'($module, z, base=e, /)'

But, unfortunately (and that's coming from the inspect module logic in RewriteSymbolics):

>>> help(cmath.log)
Help on built-in function log in module cmath:

log(z, base=2.718281828459045, /)
    log(z[, base]) -> the logarithm of z to the given base.

    If the base not specified, returns the natural logarithm (base e) of z.

Something like this is possible with a tentative patch attached (with work with base=cmath.e too):

>>> inspect.signature(cmath.log)
<Signature (z, base=e, /)>
>>> help(cmath.log)
Help on built-in function log in module cmath:

log(z, base=e, /)
    log(z[, base]) -> the logarithm of z to the given base.

    If the base not specified, returns the natural logarithm (base e) of z.

inspect-sym-defs.diff.txt

mdickinson · 2023-01-30T18:57:49Z

Thanks for your thoughtful comments, @rhettinger. I'll take a second look at this.

One way or another, I would like to see these signature errors fixed. It's not at all uncommon for third-party libraries to apply inspect.signature (or something that depends on it, like inspect.getfullargspec) to a callback function to determine how to call that callback. This is an issue I've encountered in real code. It's not hard to work around - you just have to supply a pure Python wrapper for the target function - but it's annoying to have to do so when there's no good reason for inspect.signature not to work out of the box.

mdickinson · 2023-01-30T18:58:56Z

FWIW, it does look as though simply removing the argument clinic wrapping for math.log and cmath.log may be the easiest solution here - that gives us full control over the docstring.

rhettinger · 2023-01-30T22:57:40Z

@mdickinson

One way or another, I would like to see these signature errors fixed.

That is a reasonable aspiration. However we should remain cognizant that the root problem is that Signature objects are currently incapable of expressing a union of log(x) and log(x, base) without having to make base nullable. ISTM that people should be working on that problem rather than damaging the underlying functions to fit within the limitations of signature objects. Those would be a permanent API changes that we would regret later when inspect and Signature eventually get the necessary build outs.

FWIW, it does look as though simply removing the argument clinic wrapping for math.log and cmath.log may be the easiest solution here - that gives us full control over the docstring.

I agree that a straight docstring edit seems like the most reasonable thing to do. It leaves the actual function undamaged and doesn't mangle the API.

Until now, we've had a policy of deferring AC/signature work on any function that didn't fit. For example, inspect.signature(range) and inspect.signature(dict.pop) raise a ValueError because their argument patterns are not expressible by signature objects.

Perhaps we need a new Zen of Python entry: Resist the temptation to square a circle ;-)

@skirpichev

About benchmarks. ...

FWIW, tight timing loops with 100% predictable branches almost always fail to report the actual cost of the test in real code. See this famous SO question and answer to understand why.

Note that the C log() function is very fast. Our runtime is dominated by the argument parsing overhead. That is why log(x) runs only half as fast as log2(x) or log10(x). Much of the rest of the overhead is due to the cost of handling non-finite values and the cost of creating the float object result.

@hauntsaninja

showing the base explicitly, @mdickinson expressed some concern about about implying that math.log(x) is equivalent to math.log(x, math.e)

I share those concerns. IIRC @serhiy-storchaka put in the math.e default in the docstring, but that isn't strictly correct. I would have expected something along the lines of:

Help on built-in function log in module math:

       math.log(x)
       math.log(x, base)

      Computes the logarithm of *x* for the given *base*. 
      If the *base* is not provided, compute the natural logarithm.

      Natural logarithms are based on Euler's number, a mathematical
      constant approximately equal to 2.71828.

Side note: It may be instructive to look at how Microsoft Excel documents their log() and ln() functions. In general, their docs represent a gold standard for being almost universally understood by broad classes of end users.

skirpichev · 2023-01-31T01:52:21Z

I would like to see these signature errors fixed.

@mdickinson, could you then take a second look on #101123? (It's much simpler, anyway.) This is the case where the Signature object can handle function signature properly. (And BTW, the code has an unclear comment on why this wasn't moved to the Argument Clinic.)

simply removing the argument clinic wrapping for math.log and cmath.log may be the easiest solution here

So far, one major issue with the docstring is that the first line doesn't mention the default base case. For that part we have full control over the auto-generated code...

And IIUIC, with this solution we keep inspect.signature()'s broken.

put in the math.e default in the docstring, but that isn't strictly correct.

Yes, it will be correct with a some kind of symbolic constant (that corresponds to the real number e) instead of the math.e (inexact representation).

Note that the C log() function is very fast. Our runtime is dominated by the argument parsing overhead.

@rhettinger, I'm not pretending that I did measurements of Py_None vs NULL overhead. But there is a clear difference in timings, I think mostly from the auto-generated (by AC) code:

git checkout 0ef92d9793^ && make -s
./python -m timeit -s 'from math import log' 'log(1.1)' # before patch
# 1000000 loops, best of 5: 362 nsec per loop
git checkout 0ef92d9793 && make -s
./python -m timeit -s 'from math import log' 'log(1.1)' # after
# 2000000 loops, best of 5: 165 nsec per loop
git checkout 0ef92d9793^
wget -q -O https://patch-diff.githubusercontent.com/raw/python/cpython/pull/101115.diff|git apply; make -s
./python -m timeit -s 'from math import log' 'log(1.1)' # on the PR #101115
# 2000000 loops, best of 5: 169 nsec per loop

It may be instructive to look at how Microsoft Excel documents their log() and ln() functions

And then take a look on their log function Description ("Returns the logarithm of a number to the base you specify."). I believe it's that corresponds to the first line of python's docstrings. Their Syntax section describes the function signature ("LOG(number, [base])"), but it also doesn't specify the default value. And if we construct a tooltip from those parts only...

diff --git a/Modules/mathmodule.c b/Modules/mathmodule.c
index e6cdb3bae1..e357eb5336 100644
--- a/Modules/mathmodule.c
+++ b/Modules/mathmodule.c
@@ -2369,10 +2369,7 @@ math.log
     base: object = None
     /
 
-Return the logarithm of x to the given base.
-
-If the base is not specified or is None, returns the natural
-logarithm (base e) of x.
+Return the logarithm of x to the given base or the natural logarithm (base e).
 [clinic start generated code]*/
 
 static PyObject *

How about this solution for the tooltip problem? Or just "Return the logarithm of x to the given base or the natural logarithm of x": "(base e)" has disadvantage of different meanings (real number e vs math.e), while it's clearly assumed that the math module user knows what is the natural logarithm of x. (E.g. docstring acosh(x) says: "Return the inverse hyperbolic cosine of x.")

skirpichev · 2023-01-31T03:41:46Z

BTW, the None default is coming with math.perm() function (with a different semantics, k=None <=> k=n). And here we also have an issue with tooltip:

…hon#101404)" This reverts commit 0ef92d9.

mdickinson · 2023-02-05T12:51:54Z

I've created PR #101580 to revert, to give us some space to consider possible alternative solutions. However, I'm far from convinced by Raymond's claim of the optional None argument representing "damage" to the function API. I'd like a wider discussion on this, and propose to open a discussion on discuss.org. I'll post the link here when I've done so.

arhadthedev · 2023-02-05T12:55:59Z

discuss.org

discuss.python.org?

mdickinson · 2023-02-05T13:05:57Z

@arhadthedev discuss.python.org indeed! Thank you.

Discussion opened at https://discuss.python.org/t/should-none-defaults-for-optional-arguments-be-discouraged/23554

…#101580) This reverts commit 0ef92d9.

Restored 0ef92d9 after reversion in python#101580

mdickinson · 2023-03-04T13:10:56Z

Closing as "won't fix".

mdickinson added 3.9 3.10 3.11 extension-modules type-bug labels Sep 16, 2021

ezio-melotti transferred this issue from another repository Apr 10, 2022

bedevere-bot mentioned this issue Jan 16, 2023

gh-89381: Fix invalid signatures of math/cmath.log #101070

Closed

mdickinson added 3.12 and removed 3.9 labels Jan 16, 2023

bedevere-bot mentioned this issue Jan 18, 2023

gh-89381: Fix signature for math.log and cmath.log #101115

Closed

bedevere-bot mentioned this issue Jan 29, 2023

gh-89381: Fix invalid signatures of math/cmath.log #101404

Merged

hauntsaninja closed this as completed Jan 29, 2023

rhettinger reopened this Jan 29, 2023

mdickinson self-assigned this Jan 30, 2023

mdickinson added a commit to mdickinson/cpython that referenced this issue Feb 5, 2023

Revert "pythongh-89381: Fix invalid signatures of math/cmath.log (pyt…

d1daa27

…hon#101404)" This reverts commit 0ef92d9.

mdickinson mentioned this issue Feb 5, 2023

Revert "gh-89381: Fix invalid signatures of math/cmath.log (#101404)" #101580

Merged

mdickinson added a commit that referenced this issue Feb 5, 2023

Revert "gh-89381: Fix invalid signatures of math/cmath.log (#101404)" (…

0672a6c

…#101580) This reverts commit 0ef92d9.

skirpichev mentioned this issue Feb 6, 2023

1st line of the math.perm docstring doesn't mention a default value for k #101592

Closed

skirpichev added a commit to skirpichev/cpython that referenced this issue Feb 6, 2023

pythongh-89381: Fix invalid signatures of math/cmath.log (python#101404)

5a8d031

Restored 0ef92d9 after reversion in python#101580

skirpichev mentioned this issue Feb 6, 2023

gh-89381: Fix invalid signatures of math/cmath.log (v2) #101593

Closed

skirpichev mentioned this issue Feb 19, 2023

Incorrect docstring of math.exp (math.e vs Euler's number) #101594

Closed

mdickinson closed this as not planned Mar 4, 2023

skirpichev mentioned this issue Mar 20, 2023

Speedup math.log by removing AC stuff #102839

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Sponsors

cmath.log has an invalid signature #89381

cmath.log has an invalid signature #89381

mdickinson commented Sep 16, 2021 •

edited by bedevere-bot

Loading

mdickinson commented Sep 16, 2021

mdickinson commented Sep 16, 2021

mdickinson commented Sep 16, 2021

mdickinson commented Sep 16, 2021

vstinner commented Sep 16, 2021

skirpichev commented Jan 16, 2023

hauntsaninja commented Jan 18, 2023 •

edited

Loading

hauntsaninja commented Jan 18, 2023 •

edited

Loading

skirpichev commented Jan 18, 2023

hauntsaninja commented Jan 18, 2023

skirpichev commented Jan 19, 2023

fochoao commented Jan 19, 2023

fochoao commented Jan 19, 2023

rhettinger commented Jan 29, 2023

rhettinger commented Jan 29, 2023

hauntsaninja commented Jan 29, 2023 •

edited

Loading

skirpichev commented Jan 30, 2023 •

edited

Loading

mdickinson commented Jan 30, 2023

mdickinson commented Jan 30, 2023

rhettinger commented Jan 30, 2023 •

edited

Loading

skirpichev commented Jan 31, 2023 •

edited

Loading

skirpichev commented Jan 31, 2023 •

edited

Loading

mdickinson commented Feb 5, 2023

arhadthedev commented Feb 5, 2023

mdickinson commented Feb 5, 2023 •

edited

Loading

mdickinson commented Mar 4, 2023

cmath.log has an invalid signature #89381

cmath.log has an invalid signature #89381

Comments

mdickinson commented Sep 16, 2021 • edited by bedevere-bot Loading

Linked PRs

mdickinson commented Sep 16, 2021

mdickinson commented Sep 16, 2021

mdickinson commented Sep 16, 2021

mdickinson commented Sep 16, 2021

vstinner commented Sep 16, 2021

skirpichev commented Jan 16, 2023

hauntsaninja commented Jan 18, 2023 • edited Loading

hauntsaninja commented Jan 18, 2023 • edited Loading

skirpichev commented Jan 18, 2023

hauntsaninja commented Jan 18, 2023

skirpichev commented Jan 19, 2023

fochoao commented Jan 19, 2023

fochoao commented Jan 19, 2023

rhettinger commented Jan 29, 2023

rhettinger commented Jan 29, 2023

hauntsaninja commented Jan 29, 2023 • edited Loading

skirpichev commented Jan 30, 2023 • edited Loading

mdickinson commented Jan 30, 2023

mdickinson commented Jan 30, 2023

rhettinger commented Jan 30, 2023 • edited Loading

skirpichev commented Jan 31, 2023 • edited Loading

skirpichev commented Jan 31, 2023 • edited Loading

mdickinson commented Feb 5, 2023

arhadthedev commented Feb 5, 2023

mdickinson commented Feb 5, 2023 • edited Loading

mdickinson commented Mar 4, 2023

mdickinson commented Sep 16, 2021 •

edited by bedevere-bot

Loading

hauntsaninja commented Jan 18, 2023 •

edited

Loading

hauntsaninja commented Jan 18, 2023 •

edited

Loading

hauntsaninja commented Jan 29, 2023 •

edited

Loading

skirpichev commented Jan 30, 2023 •

edited

Loading

rhettinger commented Jan 30, 2023 •

edited

Loading

skirpichev commented Jan 31, 2023 •

edited

Loading

skirpichev commented Jan 31, 2023 •

edited

Loading

mdickinson commented Feb 5, 2023 •

edited

Loading