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. 


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 <>
Python-bugs-list mailing list

Reply via email to