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 tim.peters
Recipients Camion, gvanrossum, rhettinger, tim.peters
Date 2021-01-11.02:32:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Any principled change costs more than it's worth :-(

I'm mostly sympathetic with Guido's view, and have long advocated a new `imath` module to hold the ever-growing number of functions that are really part of integer combinatorics.  But it's become nearly impossible to add a new module anymore:  python-ideas can't maintain any focus, python-dev has become an eternal circular debating society, and "put it on pyPI first to see whether it's adopted" has become a go-to bait-&-switch scam (e.g., witness Grant Jenks's `sortedcontainers` module, which is absolutely first rate, and widely used, but "why add it to the core? it's already on pyPI" has shut down any suggestion to fold it in - although I don't know that Grant would _want_ to fold it in).

OTOH, I don't agree `math` should be limited solely to floats.  It would be, e.g., pointlessly annoying for things like `pow(x, 4)` or `atan(1)` to blow up just because an argument is an int instead of a float.  I have no problem with limiting `math` functions to the simple scalar types that also work in C libm calls (where ints aren't a problem because the compiler inserts coercions to double). As a slight extension then, I have no problem either with log(1 << 1000000) working, because Python doesn't have C's distinctions between integer sizes.  So, overall, "floats or ints, but generally just the functions C's <math.h> defines".  Which is pretty much how `math` started.

But I don't see a realistic way to get there from here. Even though I'm retired now, I don't _want_ to spend 16 hours arguing every day for months - that's a major percentage of my remaining expected life ;-)

For other approaches, people doing serious work already solve it the obvious way. For example, the spiffy arbitrary-precision `mpmath` binary float module supplies its own versions of libm functions, that work on the numeric types it defines. It's not a real problem in real life that they don't also work on Fraction or Decimal. In fact, I'm glad they don't! It would usually be "an error" in my code if I tried to pass a Decimal to an mpmath function, because I'm using mpmath to begin with precisely because I _intend_ to work specifically and only with mpmath's numeric types for the duration.

So we can keep this report open forever waiting for a miracle, or yield to reality and close it as "sorry - won't fix" now ;-)
Date User Action Args
2021-01-11 02:32:57tim.peterssetrecipients: + tim.peters, gvanrossum, rhettinger, Camion
2021-01-11 02:32:56tim.peterssetmessageid: <>
2021-01-11 02:32:56tim.peterslinkissue42886 messages
2021-01-11 02:32:56tim.peterscreate