[A.M. Kuchling]
> ...
> * Begin changing places that raise OverflowError, to create long
> integers instead. (Or maybe this is a bad idea; certainly it might
> break existing code.)
It's a darned interesting question! This is the kind of thing I was worried
about.
I have a lot of int code in try blocks that catches OverflowError, but, when
it happens, I redo the whole darn algorithm from scratch after promoting
oodles of stuff to long! This is in situations where I expect that faster
int arithmetic will usually work, but don't mind slower long arithmetic when
necessary. All that would still work fine (it simply wouldn't trigger
OverflowError anymore). Note this is done routinely in Demo/classes/Rat.py
(which isn't mine, so I'm not the only one <wink>).
At least a dozen copies of this are floating around my modules:
def chop(n, int=int):
"""Return int(n) if no overflow, else n.
"""
try:
return int(n)
except OverflowError:
return n
This is usually just to get rid of the trailing "L" in output whenever
possible, and sometimes to speed later operations.
Etc. I think all my code would work fine. But then there's Guido's
faqwiz.py:
try:
cutoff = now - days * 24 * 3600
except OverflowError:
cutoff = 0
The intent there isn't at all obvious, although in context I think it would
continue to work.
After a quick but not entirely careless scan, I didn't see anything in the
std distribution that's likely to break other than the OverflowError tests.
It would usually *allow* rewriting to simpler, clearer, and probably faster
(if long ops automagically cut back small-enough results to internal ints)
code.
glad-i'm-not-the-dictator<wink>-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4