This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients brett.cannon, christian.heimes, lemburg, miss-islington, ned.deily, zach.ware
Date 2021-10-24.10:55:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 23.10.2021 21:30, Christian Heimes wrote:
> The trick would move the math function back into the core. Mark moved the math functions out of the core on purpose, see bpo-7518.

I don't follow you. With the _math.o target in,
_math.c was always compiled into the main Python interpreter,
even with math and cmath built as shared libs.

And yes, it does export a symbol, but _Py_log1p is not going to
conflict with anything else out there :-)

The trick is essentially not changing the 3.10 status quo. It
only makes sure that _math.o is compiled in the same way as all
other Setup managed modules and moves the target from
to the makesetup section of the final Makefile.

And it removes the warning of having multiple _math.o targets
ending up in the Makefile, which isn't problematic, since make
will always use the last definition (from the makesetup section),
but doesn't look nice either.

OTOH, _math.h and .c are really small, so perhaps it's better
to merge both into a single _math.h file and include that directly
into the modules. I believe that's what Brett's patch does, right ?

Today, only the _Py_log1p() code is actually used and then only
to address a very special case in a platform independent way
(log1p(-0.0) == -0.0), so the whole code boils down to some 10
lines of C being incorporated.
Date User Action Args
2021-10-24 10:55:42lemburgsetrecipients: + lemburg, brett.cannon, christian.heimes, ned.deily, zach.ware, miss-islington
2021-10-24 10:55:42lemburglinkissue45548 messages
2021-10-24 10:55:41lemburgcreate