Add shutil.ignore_patterns() to shutil.rmtree()
Hi Folks, I have a task to synchronize folders but some files should be remained untouched. I think this is a very common task. I found that shutil.copytree() has ignore_patterns() but rmtree() has not. So here comes my idea: add ignore_patterns() to rmtree() it is a good feature and makes the functions symmetric. BR, George
On 05.05.17 10:58, George Fischhof wrote:
I have a task to synchronize folders but some files should be remained untouched. I think this is a very common task.
I found that shutil.copytree() has ignore_patterns() but rmtree() has not.
So here comes my idea: add ignore_patterns() to rmtree() it is a good feature and makes the functions symmetric.
You can't remove a tree when remain its branches. Thus rmtree() with ignore_patterns will always fail. For your particular case I suggest to use os.walk(). You can implement arbitrary application specific conditions.
2017-05-05 11:52 GMT+02:00 Serhiy Storchaka
On 05.05.17 10:58, George Fischhof wrote:
I have a task to synchronize folders but some files should be remained untouched. I think this is a very common task.
I found that shutil.copytree() has ignore_patterns() but rmtree() has not.
So here comes my idea: add ignore_patterns() to rmtree() it is a good feature and makes the functions symmetric.
You can't remove a tree when remain its branches. Thus rmtree() with ignore_patterns will always fail.
For your particular case I suggest to use os.walk(). You can implement arbitrary application specific conditions.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
If the remaining equals to ignore_pattern plus the container folders, then it is succesful ;-) In my opinion
Hi!
On Fri, May 05, 2017 at 09:58:15AM +0200, George Fischhof
Hi Folks,
I have a task to synchronize folders but some files should be remained untouched.
Synchronize folders using rmtree()? I don't get it.
I think this is a very common task.
I think it is not that common.
I found that shutil.copytree() has ignore_patterns() but rmtree() has not.
So here comes my idea: add ignore_patterns() to rmtree() it is a good
rmtree() is like ``rm -r``, not like ``find . -name *.pyc -delete``.
feature and makes the functions symmetric.
Why impose artificial symmetry?
BR, George
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
2017-05-05 13:02 GMT+02:00 Oleg Broytman
Hi!
On Fri, May 05, 2017 at 09:58:15AM +0200, George Fischhof < george@fischhof.hu> wrote:
Hi Folks,
I have a task to synchronize folders but some files should be remained untouched.
Synchronize folders using rmtree()? I don't get it.
I think this is a very common task.
I think it is not that common.
I found that shutil.copytree() has ignore_patterns() but rmtree() has not.
So here comes my idea: add ignore_patterns() to rmtree() it is a good
rmtree() is like ``rm -r``, not like ``find . -name *.pyc -delete``.
feature and makes the functions symmetric.
Why impose artificial symmetry?
BR, George
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Actually it would be good if copytree() would be able to overwrite files and directories. George
On Fri, May 05, 2017 at 03:55:37PM +0200, George Fischhof
Actually it would be good if copytree() would be able to overwrite files and directories.
Seems you want rsync, no?
George
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
yes, something like that ... ;-) but I use windows, and I want the feature
in Python, with a simple and elegant way (1-2 commands)
2017-05-05 16:14 GMT+02:00 Oleg Broytman
On Fri, May 05, 2017 at 03:55:37PM +0200, George Fischhof < george@fischhof.hu> wrote:
Actually it would be good if copytree() would be able to overwrite files and directories.
Seems you want rsync, no?
George
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, May 05, 2017 at 04:50:07PM +0200, George Fischhof
yes, something like that ... ;-) but I use windows, and I want the feature in Python, with a simple and elegant way (1-2 commands)
2017-05-05 16:14 GMT+02:00 Oleg Broytman
: On Fri, May 05, 2017 at 03:55:37PM +0200, George Fischhof < george@fischhof.hu> wrote:
Actually it would be good if copytree() would be able to overwrite files and directories.
Seems you want rsync, no?
I can understand the need but I don't think such a library/script should be in stdlib. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
2017. máj. 5. du. 7:02 ezt írta ("Oleg Broytman"
yes, something like that ... ;-) but I use windows, and I want the feature in Python, with a simple and elegant way (1-2 commands)
2017-05-05 16:14 GMT+02:00 Oleg Broytman
: On Fri, May 05, 2017 at 03:55:37PM +0200, George Fischhof < george@fischhof.hu> wrote:
Actually it would be good if copytree() would be able to overwrite files and directories.
Seems you want rsync, no?
I can understand the need but I don't think such a library/script should be in stdlib. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ But if shutil.copytree would be able to overwrite, it would be good, and simetimes enough. And I think it is not too difficult to implement ;-)
participants (3)
-
George Fischhof
-
Oleg Broytman
-
Serhiy Storchaka