[Python-Dev] Patches: 1 for the price of 10.

[Josiah Carlson]

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?

Precision.
>>> 2.0**52
4503599627370496.0
>>> 2.0**52+1
4503599627370497.0
>>> 2.0**53
9007199254740992.0
>>> 2.0**53+1
9007199254740992.0

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".


 - Josiah