-> > 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? 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. The patch (with a bit more code context) is: -- if (!PyArg_ParseTuple(args, "O|i:seek", &offobj, &whence)) return NULL; #if !defined(HAVE_LARGEFILE_SUPPORT) offset = PyInt_AsLong(offobj); #else + if(PyFloat_Check(offobj)) { + offobj = PyLong_FromDouble(PyFloat_AsDouble(offobj)); + } offset = PyLong_Check(offobj) ? PyLong_AsLongLong(offobj) : PyInt_AsLong(offobj); #endif -- so the issue only comes into play with large file support. Heh, and I just noticed that PyLong_FromDouble returns a new reference, so this is a memory leak, I believe. Whoooops. I'll fix that. cheers, --titus