On Wed, Aug 03, 2016 at 11:31:46AM -0700, Guido van Rossum wrote:
Then again are people really concerned about the speed of those file copy functions? Or are we just offering a solution in search of a problem?
At kernel level: clearly yes, otherwise their BDFL would noy allow those[1] patches to go in. Now, should/could Python benefit from them? I personally think so, that it should. That's why I developed the patch in the first place. As for the cost, in terms of maintainability, I just noticed that copy() and copy2() use copyfile(), and that copytree() uses copy2(), so only one function should be modified. True, the code will be ~50% more complex (it needs to check the availability of the function and the suitability for the parameters given; copy_file_range() only works on files on the same filesystem[1]). Hmm... Maybe you're right. Maybe, to keep Python's own code simple, we could skip these optimizations, and leave them in a 3rd party module. -- [1] I still don't understand why all these optimizations are exposed separately for the specific cases in which they work; I would expect one function that would take care of the details, but at least provide copy functionality without using user space buffers but kernel ones. But then, I'm not a kernel developer, just a puny Python one... -- (Not so) Random fortune: Terrorism isn't a crime against people or property. It's a crime against our minds, using the death of innocents and destruction of property to make us fearful. -- Bruce Schneier