> How would it work? The C lseek() takes a signed (64-bit) offset
> as argument, so we would have to call it multiple times anyway.

Python does already call multiple times the same function if the input is larger than the type used by the function. Some examples:

 - mbcs codec: work on chunk on INT_MAX bytes (input size type: Py_ssize_t)
 - zlib: crc32() works on chunk on UINT_MAX bytes (input size type: Py_ssize_t)

We have also functions processing fewer data if the function cannot handle all data: FileIO.write() clamps the buffer size of INT_MAX on Windows for example.

If we call lseek() multiple times, the implementation will depend on the whence value: SEEK_SET will use SEEK_SET and then SEEK_CUR. For SEEK_CUR, all calls can use SEEK_CUR. For SEEK_END... hum? SEEK_END and then SEEK_CUR?

I vote -1 for this feature because I bet that the behaviour of lseek() with an file position > 2^63 or offset > 2^63 highly depend on the platform (kernel, libc) version.

You can implement it in Python for your usecase. I prefer to keep a thin wrapper with an known and reliable behaviour.