You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
albertogomcasmannequin opened this issue
Aug 9, 2017
· 5 comments
Labels
3.8 (EOL)end of life3.9only security fixesdocsDocumentation in the Doc direasystdlibPython modules in the Lib dirtype-featureA feature request or enhancement
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 (reading the PEP I have seen Path instances are kind of immutable), after the call the Path instance keeps "pointing" to the previous (and quite likely now useless) path.
Returning the new path would be a reasonable option. In any case, I think the documentation should mention this behavior explicitly.
I agree. The normal python convention is that an immutable object returns the new value when an operation "changes" it, while a mutable object returns None. It seems like replace and rename should follow this convention (and that it would also be convenient).
New changeset 088a09a by Jason R. Coombs (hui shang) in branch 'master': bpo-31163: Added return values to pathlib.Path instance's rename and replace methods. (GH-13582) 088a09a
New changeset cbd7b2a by Jason R. Coombs (Miss Islington (bot)) in branch '3.8': bpo-31163: Added return values to pathlib.Path instance's rename and replace methods. (GH-13582) (GH-15944) cbd7b2a
3.8 (EOL)end of life3.9only security fixesdocsDocumentation in the Doc direasystdlibPython modules in the Lib dirtype-featureA feature request or enhancement
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: