> About changing copyfileobj(), here are some test cases which may help explain the compatibility problems:

I see, I was expecting something like that after reading https://bugs.python.org/issue25063 's conclusions. I removed that part.

> Perhaps we could keep the new version as a high-level copy_file_range() wrapper, but retain brute_force_copy() under the original copyfileobj() name. A bit like the socket.sendfile() method vs os.sendfile().

You mean having always a copy_file_range() method that in the worst case would fallback to copyfileobj()? I'm considering using it to optimize copyfile() (and indirectly copy() and copy2()) instead. 

And sorry for the patch wrong format.