Author StyXman
Recipients StyXman, christian.heimes, martin.panter, neologix, vstinner
Date 2016-04-28.13:11:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461849107.0.0.137361214121.issue26826@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2016-04-28 13:11:47StyXmansetrecipients: + StyXman, vstinner, christian.heimes, neologix, martin.panter
2016-04-28 13:11:47StyXmansetmessageid: <1461849107.0.0.137361214121.issue26826@psf.upfronthosting.co.za>
2016-04-28 13:11:46StyXmanlinkissue26826 messages
2016-04-28 13:11:46StyXmancreate