Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GH-73991: Add follow_symlinks argument to
pathlib.Path.copy()
#120519New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-73991: Add follow_symlinks argument to
pathlib.Path.copy()
#120519Changes from all commits
34a3365
38bf791
0717792
de5a230
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failing to copy a symlink that targets a directory is disappointing. A symlink is never reported as a directory in Python, so code that copies a tree that contains directory symlinks is going to fail on Windows Server 2016 and Windows Server 2019 systems, with no obvious reason that a Python programmer would reasonably expect. A fallback path is needed to copy the link via
os.symlink()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have waited for your feedback Eryk, my bad. I'll fix this in a follow-up PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As always, I defer to what you and Steve think is best.
I'm of a mixed mind regarding Python's PEP 11 support policy that requires new versions of Python to support Server releases that still have extended support from Microsoft, which sets the bar for all versions of Windows. The Server editions are released in the LTSC channel and get 10 years of support. Server 2016 (build 14393) is supported until January 2027, and Server 2019 (build 17763) is supported until January 2029. Part of me wishes we just grouped the Server releases with corresponding releases in the general availability channel (e.g. Windows 10 1607 and Windows 10 1809) because it's more work to provide and maintain fallback paths for older versions of Windows. However, it's also great for users that they can use the latest version of Python on older systems.