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-29.01:43:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461894187.06.0.907553969728.issue26826@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, having a high-level version of copy_file_range() that falls back to copyfileobj() should be okay. I’m not sure if it should be a public API of shutil, or just an internal detail.

I am wondering if it would be nice to rearrange the os.copy_file_range() signature and make more parameters optional, or is that getting too high level?

copy_file_range(in, out, count, offset_in=None, offset_out=None, flags=0)

copy_file_range(f1, f2, size)  # Try to copy a whole file
copy_file_range(f1, f2, 30, 100, 200)  # Try 30 bytes at given offsets

Also left some more review comments. Also, we should eventually add test case(s) for the new functionality, and an entry to Doc/whatsnew/3.6.rst.
History
Date User Action Args
2016-04-29 01:43:07martin.pantersetrecipients: + martin.panter, vstinner, christian.heimes, StyXman, neologix
2016-04-29 01:43:07martin.pantersetmessageid: <1461894187.06.0.907553969728.issue26826@psf.upfronthosting.co.za>
2016-04-29 01:43:06martin.panterlinkissue26826 messages
2016-04-29 01:43:05martin.pantercreate