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.

classification
Title: Add use_srcentry parameter to shutil.copytree()
Type: enhancement Stage: patch review
Components: Documentation, Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: giampaolo.rodola, xxxxxxx
Priority: normal Keywords: patch, patch, patch, patch

Created on 2019-01-03 09:06 by xxxxxxx, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11421 closed xxxxxxx, 2019-01-03 09:07
PR 11421 closed xxxxxxx, 2019-01-03 09:07
PR 11421 closed xxxxxxx, 2019-01-03 09:07
PR 11421 closed xxxxxxx, 2019-01-03 09:07
PR 11997 giampaolo.rodola, 2019-02-23 17:17
PR 11425 xxxxxxx, 2019-02-24 17:46
Messages (6)
msg332923 - (view) Author: (xxxxxxx) * Date: 2019-01-03 09:06
Currently it is decided if to use the srcentry in the copy_function by checking if the copy_function is copy() or copy2(). This will fail if the copy_function is a modified copy() or copy2() function. To control if the copy_function gets a srcentry or srcname parameter, added the use_srcentry parameter.
msg332942 - (view) Author: (xxxxxxx) * Date: 2019-01-03 19:09
A new PR is started.
See https://bugs.python.org/issue35652 and https://github.com/python/cpython/pull/11425
msg336392 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2019-02-23 17:17
It turns out that's a bug I introduced in PR-7874. I'm providing:
https://github.com/python/cpython/pull/11997
...which fixes it without introducing a new parameter. I also verified that monkey patching shutil.copy2 and shutil.copy doesn't cause any issue.
msg336394 - (view) Author: (xxxxxxx) * Date: 2019-02-23 18:02
You are right about the bug. The funny thing is, I never saw it.

The problem I see is another.
The use_srcentry variable in the _copytree function is set by determining if the copy_function is the function copy2 or copy. If so the srcentry is passed to the copy_function. If the user passes a custom copy_function to copytree, this function will ever become only the srcname and not the srcentry. To summarize it: The integrated copy_functions get the srcentry and custom copy_functions get the srcname.
But what is if the custom copy_function is a edited copy2 function or needs the srcentry? In order to fix this was my idea to have a parameter to control if the custom copy_function get the srcentry or a srcname.
Please write me if there is anything misconception in my thoughts or other objections?
msg336452 - (view) Author: Giampaolo Rodola' (giampaolo.rodola) * (Python committer) Date: 2019-02-24 09:13
When user uses copy_function argument, the callback function should always receive path strings, both for consistency and for not breaking backward compatibility. This line:

    use_srcentry = copy_function is copy2 or copy_function is copy

...makes sure of that (only passes DirEntry instances around if copy_function is not specified by user).
msg336479 - (view) Author: (xxxxxxx) * Date: 2019-02-24 17:46
Okay, than this behaviour is wanted.
I only thought that the user should have more control about it, but you are right, only the path string is better to handle.
I will close the PR.
History
Date User Action Args
2022-04-11 14:59:09adminsetgithub: 79829
2019-02-24 17:46:05xxxxxxxsetstatus: open -> closed

resolution: not a bug
messages: + msg336479
pull_requests: + pull_request12051
2019-02-24 09:13:35giampaolo.rodolasetkeywords: patch, patch, patch, patch

messages: + msg336452
2019-02-23 18:02:42xxxxxxxsetmessages: + msg336394
2019-02-23 17:17:38giampaolo.rodolasetnosy: + giampaolo.rodola
messages: + msg336392
pull_requests: + pull_request12026

keywords: patch, patch, patch, patch
stage: resolved -> patch review
2019-02-23 16:37:33giampaolo.rodolasetkeywords: patch, patch, patch, patch
assignee: docs@python ->
status: closed -> open
resolution: later -> (no value)
2019-01-03 19:09:37xxxxxxxsetstatus: open -> closed

nosy: - docs@python
messages: + msg332942

resolution: later
stage: patch review -> resolved
2019-01-03 09:07:58xxxxxxxsetkeywords: + patch
stage: patch review
pull_requests: + pull_request10834
2019-01-03 09:07:52xxxxxxxsetkeywords: + patch
stage: (no value)
pull_requests: + pull_request10835
2019-01-03 09:07:46xxxxxxxsetkeywords: + patch
stage: (no value)
pull_requests: + pull_request10833
2019-01-03 09:07:41xxxxxxxsetkeywords: + patch
stage: (no value)
pull_requests: + pull_request10832
2019-01-03 09:06:12xxxxxxxcreate