| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
This used to raise an OSError with a platform dependent message. This change always raises a SpecialFileError with a consistent message no matter the platform.
|
Thanks for the PR @AWhetter! |
Sorry, something went wrong.
There was a problem hiding this comment.
This looks good to me! I would maybe just change the NEWS entry to be less wordy:
:func:`shutil.copyfile` always raises a :exc:`shutil.SpecialFileError` when trying to copy a Unix socket.
Sorry, something went wrong.
Sorry, something went wrong.
|
Good idea. I'll get that changed. |
Sorry, something went wrong.
|
I think it helps everyone follow the flow of the PR when things aren't force pushed and history isn't rewritten. It will get squashed in the end, anyways! I just break up my commits so that the individual diffs are easy to follow. So if I'm editing and moving a function, I'll do those in separate commits in order to preserve an easy-to-follow storyline. |
Sorry, something went wrong.
|
Similar to the issue mentioned in bpo-37701, this raises SpecialFileError when src or dest are symlinks to a socket file. |
Sorry, something went wrong.
| else: | ||
| self.fail("shutil.Error should have been raised") | ||
| finally: | ||
| shutil.rmtree(TESTFN2, ignore_errors=True) |
There was a problem hiding this comment.
This seems unnecessary as per:
self.addCleanup(shutil.rmtree, TESTFN, ignore_errors=True)
...some lines above.
Sorry, something went wrong.
| shutil.rmtree(TESTFN2, ignore_errors=True) | ||
|
|
||
| @unittest.skipUnless(hasattr(socket, 'AF_UNIX'), 'requires socket.AF_UNIX') | ||
| def test_copytree_socket(self): |
There was a problem hiding this comment.
IMO testing also copytree() is not very useful since internally it uses copyfile (which you are testing).
Sorry, something went wrong.
There was a problem hiding this comment.
I was copying what was done for named pipes for consistency. But having a test for copytree() makes sense to me because if in the future copytree() stopped using copyfile() for some reason, we would still want copytree() to raise an error?
Sorry, something went wrong.
| *dst* and return *dst* in the most efficient way possible. | ||
| *src* and *dst* are path-like objects or path names given as strings. | ||
|
|
||
| When *src* is a named pipe or a Unix socket, a :exc:`SpecialFileError` |
There was a problem hiding this comment.
- When *src* is a named pipe or a Unix socket, a :exc:`SpecialFileError`
+ When *src* is a named pipe or a Unix socket, :exc:`SpecialFileError`
Sorry, something went wrong.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request. |
Sorry, something went wrong.
|
I have made the requested changes; please review again |
Sorry, something went wrong.
|
Thanks for making the requested changes! @giampaolo: please review the changes made to this pull request. |
Sorry, something went wrong.
|
Is there anything else that I can do to help progress this review? |
Sorry, something went wrong.
|
@giampaolo can this PR be unblocked? |
Sorry, something went wrong.
|
@arhadthedev thanks for the quick response! |
Sorry, something went wrong.
|
shutil.SpecialFileError seems to be undocumented. Would anybody add it into the documentation via a separate PR? |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This used to raise an OSError with a platform dependent message.
This change always raises a SpecialFileError with a consistent message
no matter the platform.
Tackling special devices wasn't part of the original issue, but it is still technically an issue. Although devices are technically copyable (at least they are with cp), they will likely hang the same as a named pipe would even though a named pipe is technically copyable as well.
https://bugs.python.org/issue37700