[Python-Dev] Patches: 1 for the price of 10.
jcarlson at uci.edu
Thu Dec 23 17:43:53 CET 2004
Titus Brown <titus at caltech.edu> wrote:
> -> > 1067760 -- float-->long conversion on fileobj.seek calls, rather than
> -> > float-->int. Permits larger floats (2.0**62) to match large
> -> > int (2**62) arguments. rhettinger marked as "won't fix" in
> -> > the original bug report; this seems like a clean solution,
> -> > tho. Recommend apply.
> -> Wouldn't this cause subtle errors when the float -> long conversion is
> -> no longer precise? Or is this a non issue because it could only happen
> -> when seeking on impossibly large files?
> When would the float --> long conversion not be precise? The docs
> say PyLong_FromDouble takes the integer part, so it's like doing
> a floor(), yes?
Anything above float(2**53-1) (one must be careful about the order of
float conversions) are basically useless for offsets into files.
> The current behavior is to convert directly from float to int, even
> though seek() can take longs as an argument. Thus 2.0**31 works,
> 2**31 works, 2**62 works, but 2.0**62 doesn't. This seems mildly
> inconsistent and prompted the guy to submit a bug report, and then
> a patch.
"works" and "doesn't work" aren't precise. "doesn't raise an exception"
and "does raise an exception" are precise. Note the above float
precision precision example about why even non-exceptions may not "work".
More information about the Python-Dev