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 belopolsky
Recipients belopolsky, mark.dickinson, rhettinger, stutzbach
Date 2010-05-12.00:12:29
SpamBayes Score 0.00029742921
Marked as misclassified No
Message-id <AANLkTin7wxsEQzhr6smLX8YKYtBy26v5K6I1bDiHNnJl@mail.gmail.com>
In-reply-to <AANLkTilraSE7gFoSVOsuN7LPFhWavoEMMBjil-IqB_gP@mail.gmail.com>
Content
On Tue, May 11, 2010 at 7:42 PM, Daniel Stutzbach
<report@bugs.python.org> wrote:
..
> Isn't that adding an extra check in every case to speed up a
> you-can't-seriously-expect-that-to-work corner case?
>

The check is cheap - just a machine integer comparison, so I would not
even take that cost into account.   In my view math.factorial() is
primarily of interest in educational settings where it is quite likely
that someone would be curious enough to pass sys.maxsize to it.

The main value in setting a theoretically justified limit is that
overflow exception can carry a meaningful message, e.g. "factorial
result would have too many digits", rather than an unhelpful "Python
int too large to convert to C long".
History
Date User Action Args
2010-05-12 00:14:45belopolskysetrecipients: + belopolsky, rhettinger, mark.dickinson, stutzbach
2010-05-12 00:13:27belopolskylinkissue8692 messages
2010-05-12 00:12:29belopolskycreate