GeezerVison

🤖 New build scheduled with the buildbot fleet by @mdickinson for commit 7d14105 🤖

If you want to schedule another build, you need to add the :hammer: test-with-buildbots label again.

What's the benefit of doing this? The downside is that we potentially introduce a quality regression on some platforms.

What's the benefit of doing this?

Less C code to maintain, perhaps?

BTW, for erf/erfc there are no failures so far.

we potentially introduce a quality regression on some platforms

It's not a for error functions, because platforms claims that they support C11 and libm's versions will play the game anyway ;) There is no such preprocessor flag as _I_M_A_BROKEN_LIBM_.

🤖 New build scheduled with the buildbot fleet by @mdickinson for commit 468096b 🤖

If you want to schedule another build, you need to add the :hammer: test-with-buildbots label again.

What's the benefit of doing this? The downside is that we potentially introduce a quality regression on some platforms.

If the patch satisfies C11 compiler requirement and PEP 11 support, it could be acceptable.

@corona10 Yes, the "this" in my comment could have been clearer.

So long as we keep this PR focused on removing what's now effectively dead code (the code that depends on HAVE_LOG2, HAVE_ERF, etc. not being defined), that's fine. It's the replacement of our own gamma and lgamma code that should be avoided - we'd be replacing tested, working code with code of unknown quality.

FWIW, speaking as the original author of the gamma and lgamma functions and maintainer of the math module, the maintenance burden from that code has been essentially zero since it was originally added.

@skirpichev Thanks for the PR! I'll have time to review properly this evening (UTC+0).

So long as we keep this PR focused on removing what's now effectively dead code

That was essentially the target of the issue.

Thank you for review and I'm sorry for a missed issue/pr (adding c11 keyword to search was too restrictive this time...)

Maybe using math_1 wrapper for erf/erfc is more safe?

Maybe using math_1 wrapper for erf/erfc is more safe?

I don't think it's needed, since erf and erfc can't overflow, and are valid over the entire real line.

I don't think it's needed, since erf and erfc can't overflow, and are valid over the entire real line.

Same is true to the tanh, for example, isn't?

I would suggest merging math_1 and math_1_to_whatever (not used anywhere else). The comment before math_1_to_whatever does mention math_1 instead. Ditto for math_1_to_whatever. (One function call less, BTW)

@mdickinson, please review last two commits.

I would suggest merging math_1 and math_1_to_whatever (not used anywhere else).

Sounds reasonable, but for ease of review let's have a separate PR for that, please! I'd like to get this one in, and that gets harder if the scope keeps changing.

Same is true to the tanh, for example, isn't?

Very likely, yes. Note that that's not a reason to change tanh as it currently is. The libm wrappers portion of the math module is highly stable, and we should be extremely conservative with changes.

Sounds reasonable, but for ease of review let's have a separate PR for that

Ok, that part (47970e2) was reverted and I've fixed prefixes for gh issues.

Note that that's not a reason to change tanh as it currently is.

Aside from some tiny performance bonus.

Status check is done, and it's a success ✅.

Aargh. And now I remember (again) why I never use the auto-merge label - there's no opportunity to edit the final commit message. :-(

Thanks for the hint. Next time I'll adjust pr title/body to follow review.

Nice change.

Shouldn't affect users, hence no news.

In the past, I tried to document these "build changes", just in case if someone is affected. Like:

The C99 functions snprintf() and vsnprintf() are now required to build Python. (Contributed by Victor Stinner in bpo-36020.)

https://docs.python.org/dev/whatsnew/3.10.html#build-changes

c11 compiler and stdlib (without optional features) were required since 3.11, so there is nothing new in that sense.