[issue26826] Expose new copy_file_range() syscal in os module and use it to improve shutils.copy()

Martin Panter report at bugs.python.org
Tue Apr 26 21:20:58 EDT 2016


Martin Panter added the comment:

Yes, the RST documentation has to be done by hand. It usually has more detail than the doc strings.

I didn’t see any changes to the configure script in your patches. Did you make that change to define HAVE_COPY_FILE_RANGE yet?

In /Modules/posixmodule.c (all three of your patches have an indented diff header, so the review doesn’t pick it up):

+#ifdef HAVE_COPY_FILE_RANGE
+/* The name says posix but currently it's Linux only */

What name are you referring to? The file posixmodule? I think the file name is a bit misleading; according to the comment at the top, it is also used on Windows.

+return (!async_err) ? posix_error() : NULL;

This would make more sense with the logic swapped around: async_err? NULL : posix_error()

Regarding copyfileobj(), I think we should continue to support file objects that do not directly wrap FileIO (includes your Unicode transcoding case). See the points given in Issue 25063. 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().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________


More information about the Python-bugs-list mailing list