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 steven.daprano
Recipients Nathaniel Manista, Vladimir Feinberg, mark.dickinson, serhiy.storchaka, steven.daprano, tim.peters
Date 2022-02-07.14:54:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1644245699.73.0.978537044364.issue46639@roundup.psfhosted.org>
In-reply-to
Content
I don't understand why math.ceildiv couldn't ducktype. There's no rule that says it *must* convert arguments to float first, that's just a convention, and we've broken it before.

>>> math.prod([Fraction(1, 3), 7])
Fraction(7, 3)

Couldn't math.ceildiv(x, y) be implemented as -(-x//y) in a type-agnostic fashion?


Perhaps it is too late in the night for me, but I have no idea what ceilrem(x, y) would do or why anyone might want it.

I agree with Vladimir that the import thing is not an issue. If we can require an import for much more important functions as sin, cos, tan, log, etc, then requiring an import is not excessive for a function of secondary importance.

Feature-bloat: its taken 30 years for somebody to request ceildiv. At that rate, it will take another 500 years for us to catch up to mpz in terms of features/bloat. I'm not losing sleep over that :-)
History
Date User Action Args
2022-02-07 14:54:59steven.dapranosetrecipients: + steven.daprano, tim.peters, mark.dickinson, serhiy.storchaka, Nathaniel Manista, Vladimir Feinberg
2022-02-07 14:54:59steven.dapranosetmessageid: <1644245699.73.0.978537044364.issue46639@roundup.psfhosted.org>
2022-02-07 14:54:59steven.dapranolinkissue46639 messages
2022-02-07 14:54:59steven.dapranocreate