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 vstinner
Recipients corona10, mark.dickinson, pablogsal, serhiy.storchaka, vstinner
Date 2020-10-01.16:31:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Mark: "I'd much prefer not. Every extra fast path check costs time for the general case, and there's no strong reason to expect people to be dividing by one. The range code seems like the right place for this optimization, not the long-divide code."

In this case, I suggest to add a comment in long_div() to explain why there is no fast-path in long_div(). Otherwise, I am likely to suggest the exact same optimization in 6 months :-D

I'm thinking at something similar to my comment in ceval.c:

        case TARGET(BINARY_ADD): {
            PyObject *right = POP();
            PyObject *left = TOP();
            PyObject *sum;
            /* NOTE(haypo): Please don't try to micro-optimize int+int on
               CPython using bytecode, it is simply worthless.
               See and
      for the discussion. In short,
               no patch shown any impact on a realistic benchmark, only a minor
               speedup on microbenchmarks. */

This comment is the outcome of 2 years of hard work by many developers :-D See bpo-21955.
Date User Action Args
2020-10-01 16:31:55vstinnersetrecipients: + vstinner, mark.dickinson, serhiy.storchaka, corona10, pablogsal
2020-10-01 16:31:55vstinnersetmessageid: <>
2020-10-01 16:31:55vstinnerlinkissue41902 messages
2020-10-01 16:31:55vstinnercreate