-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
gh-89381: Fix invalid signatures of math/cmath.log (v2) #101593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Restored 0ef92d9 after reversion in python#101580
Now this looks like cmath.log
Are we really going to accept an explicit argument Edit: to be clear, I see that it is convenient to be able to pass an explicit argument to mean 'give me the default', but |
Not yet (see the issue and mentioned discussion). That's why this is a draft.
Unfortunately, we can't pass other default in this case (no such entity as the Euler's number in the stdlib). Before it was
Yes, without this argument it's assumed to be the natural logarithm of x. The difference is just in the log function signature, it was before |
We don't have core dev consensus on this: @rhettinger in particular is strongly opposed to the introduction of |
@mdickinson, I appreciate your judgment here, but unless I miss that, the perm() function case was just ignored by @rhettinger (both in the issue and in the discussion thread). Same module, the default value was introduced by... Is that was an error, or? I see point to make the inspect module/AC more expressive to describe de-facto existing syntax (multiple signatures), that has no pure-Python counterpart yet. That clearly does make sense for more complex cases (e.g. range). But does it make sense in the given example? I'm not sure that it was shown in the discussion. Unfortunately, there are no other options suggested (c.f. multiple signatures) to solve the issue, e.g. I doubt it's possible to use base=math.e default & provide correct inspect.Signature's. And there is another, yet related, issue: log() is slow (see pr description) just to keep the "helpful and correct" "signature". Maybe it does make sense to revert the AC stuff here to workaround this? |
@skirpichev I understand (and share) your frustration, but I don't think anything's going to be achieved by further discussion here. It's not that big a deal, and it's time to let it go. |
@mdickinson, ok. But you closed the issue as well. That sounds (at least for me): "we won't any progress here at all" (that includes Raymond's suggestion). If this somehow was related to my personal involvement in the discussion - please reconsider: I can promise to be outside of any further discussions and/or any touching of math/cmath code, whatever you feel better. What I actually want - some public interface, that will allow me to add introspection capabilities to external extensions. Personally I'm satisfied with the current "state of art" (except for #101872 maybe), but now I see why all this stuff (e.g. |
Restored 0ef92d9 after reversion in #101580 (1st commit). Here is discussion opened:
https://discuss.python.org/t/should-none-defaults-for-optional-arguments-be-discouraged/23554
To solve some mentioned minor issues (on top of base=None approach):
Some benchmarks.
On the main:
With first commit:
I would guess, that some positive difference for the math.log - due to the AC difference.