[issue28060] Clean up division fast paths in Objects/longobject.c

Mark Dickinson added the comment: > What's the status of this? Forgotten, rather than abandoned. :-( I'll unassign so that someone else can pick this up. I believe the patch is ready to go, except that of course now it needs a PR. -- assignee: mark.dickinson -> _

[issue28060] Clean up division fast paths in Objects/longobject.c

Antoine Pitrou added the comment: What's the status of this? -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue28060] Clean up division fast paths in Objects/longobject.c

Serhiy Storchaka added the comment: The patch LGTM. I'll open separate issue for guaranteeing that a->ob_digit[0] is 0 in case of Py_SIZE(a) == 0 and using this fact for simplifying and optimizing the code. -- nosy: +serhiy.storchaka ___ Python trac

[issue28060] Clean up division fast paths in Objects/longobject.c

Mark Dickinson added the comment: Serhiy: thanks for the review. Replying here, since I get a 500 error every time I try to reply from Rietveld. I'd rather not rely on either NSMALLPOSINTS > 0 or on digit 0 existing when Py_SIZE is 0. We don't rely on that elsewhere, and the code should stay s

[issue28060] Clean up division fast paths in Objects/longobject.c

Mark Dickinson added the comment: N.B. The patch also tweaks the fast path condition to *include* the common case of a dividend of 0, and *exclude* the rare case of a negative divisor. (The latter change helps to keep the fast path code simple.) --

[issue28060] Clean up division fast paths in Objects/longobject.c

New submission from Mark Dickinson: We seem to have ended up with redundant fast path checks for division in longobject.c: long_div has a fast path check, but the long_div slow path calls l_divmod, which then does a second, identical, fast path check. long_mod has similar behaviour. long_divmo