Marcos Dione added the comment: > 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. ---------- Added file: http://bugs.python.org/file42638/copy_file_range.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26826> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
