Tim Peters <t...@python.org> added the comment:
I'm not rejecting anything. Mark wrote the function, and I'll defer to him. Yes, you added `initial` to `accumulate()`, and I spent hours in all explaining to you why it was an utterly natural addition, conspicuous by absence, including writing up several real-life use cases that just happened to pop up while that discussion dragged on. Thanks! I've used it many more times since it was added. Adding it brought accumulate() into line with other languages' workalikes. Python was the oddball there. OTOH, not even gmp's mpz supports rounded isqrt directly, just truncated, and a _different_ function that returns not only isqrt(n), but also "the remainder" (n - isqrt(n)**2). The latter shows they're not averse to adding cruft that can easily be done - which makes it all the more suggestive that they _didn't_ also add other rounding modes. Note: the primary intended "use case" for the version with the remainder appears to be a fast way to detect if the argument was a perfect square. As mentioned earlier, the lack of a builtin way to do that is the only complaint I've seen before about Python's isqrt. Mark didn't mention his use case for rounded isqrt, I don't have any myself, and your only named use case was "building a table of square roots incorporated in arbitrary precision functions implemented with scaled integer arithmetic". It's very hard to believe that minor speed boosts make any difference at all when building static tables, so "it's faster built in" falls flat for me. To the contrary, adding _any_ optional argument (be it a string or of any other type) complicates the calling sequence and requires burning cycles on every invocation just to work out which arguments _were_ passed. So, despite that I have no expectation of ever asking for a rounded isqrt, adding the possibility would cost _me_ cycles on every isqrt() call I already have. None of which are in one-shot table-builders, but mostly in loops. If there's a _compelling_ use case for rounded isqrt, I haven't seen one, but I'd be much happier to see it added it as a new function of its own. Like, e.g., gmp added mpz_sqrtrem() rather than add an annoying "mode" argument to the widely used mpz_sqrt(). I don't really object to string arguments per se, but in the context of what one hopes to be blazing fast integer functions, throwing in string comparisons just to set a flag seems ludicrously expensive. _PyUnicode_EqualToASCIIId() is not my idea of "cheap" ;-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46187> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
