New submission from Alberto Gomez-Casado:
I find the naming of Path.replace quite unfortunate, coming from the os.path
and basestring mindset, the expectation would be that it would change some
substring by another substring in the Path instance. Instead, it _moves_ the
file indicated by the Path object in the file system. Most of the methods of
Path have no effect in the filesystem, and we have here one with a slightly
misleading name which goes and moves your files around.
Practically the same operation is done with Path.rename, which is less
surprising since it matches popular OS commands/UIs (ren, Rename).
IMHO Path.replace should not exist as is and a keyword modifier (silent?) for
Path.rename toggles between the minor behavior differences of the two.
Additionally:
Both calls lack any kind of return, which leads me to expect after a
rename/replace the Path instance would be changed to the new path. This is not
the case, after the call the Path instance keeps "pointing" to the previous
(and quite likely now useless) path. Returning the new path would be another
reasonable option. In any case, I think the documentation should mention this
behavior explicitly.
And, while we are at it, having implemented the relatively dangerous
replace/rename (along with convenience shorcuts for reading, writing,
opening...), why was a Path.copy not included?
--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 299976
nosy: Alberto Gomez-Casado, docs@python
priority: normal
severity: normal
status: open
title: Path.replace and Path.rename naming, behavior and documentation
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31154>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
