> I agree that Python 2 should use fopen / fread rather than directly read().
> But you may misunderstand this. The 'strace' tool reports Linux system
> calls, including read() rather than fread(), and I guess that read() should
> be finally called in fread() implementation.
>
> What I mean is that Python 2's seek(0, 2) does not use fseek(0, SEEK_END),
> but fseek(somewhere, SEEK_SET) and fread(rest-bytes) instead, which is too
> inefficient in some kind of storage.

Actually, Python does use fopen(), and fseek(): the culprit is the libc:
$ cat /tmp/test.c; gcc -o /tmp/test /tmp/test.c -Wall; strace /tmp/test
open("/etc/fstab", O_RDONLY)            = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=809, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ae000
fstat64(3, {st_mode=S_IFREG|0644, st_size=809, ...}) = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
read(3, "# /etc/fstab: static file system"..., 809) = 809
close(3)                                = 0

> By the way, Python 3 does not behavior like this.

That's because in Python 3, the IO stack is implemented directly on top of open()/read()/lseek().

It's not the first time we stumble upon glibc stdio bugs.

I'd suggest closing this.