Message264429
| 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. |
|