This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients StyXman, christian.heimes, martin.panter, neologix, vstinner
Date 2016-04-27.01:20:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461720058.81.0.806711018131.issue26826@psf.upfronthosting.co.za>
In-reply-to
Content
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().
History
Date User Action Args
2016-04-27 01:20:58martin.pantersetrecipients: + martin.panter, vstinner, christian.heimes, StyXman, neologix
2016-04-27 01:20:58martin.pantersetmessageid: <1461720058.81.0.806711018131.issue26826@psf.upfronthosting.co.za>
2016-04-27 01:20:58martin.panterlinkissue26826 messages
2016-04-27 01:20:57martin.pantercreate