[Python-Dev] stuck issue 26826 (original) (raw)

Marcos Dione mdione at grulic.org.ar
Wed Aug 3 16:32:55 EDT 2016

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

More information about the Python-Dev mailing list