File-altering aspects of pathlib should return new pathlib objects

[WalterSzeliga]

BPO	29425
Nosy	@brettcannon, @pitrou, @serhiy-storchaka

^{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:

assignee = None
closed_at = None
created_at = <Date 2017-02-03.00:04:13.030>
labels = ['3.7', 'type-feature', 'library']
title = 'File-altering aspects of pathlib should return new pathlib objects'
updated_at = <Date 2017-02-07.19:04:49.858>
user = 'https://bugs.python.org/WalterSzeliga'

bugs.python.org fields:

activity = <Date 2017-02-07.19:04:49.858>
actor = 'Walter Szeliga'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2017-02-03.00:04:13.030>
creator = 'Walter Szeliga'
dependencies = []
files = []
hgrepos = []
issue_num = 29425
keywords = []
message_count = 4.0
messages = ['286835', '287164', '287218', '287252']
nosy_count = 4.0
nosy_names = ['brett.cannon', 'pitrou', 'serhiy.storchaka', 'Walter Szeliga']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue29425'
versions = ['Python 3.7']

[WalterSzeliga]

Methods on pathlib.PosixPath() and other objects that alter files on the file system should return new object instances with new information. For example, if there exists a file on the system called 'bar', then

bar_var = pathlib.PosixPath('bar')
bar_var.rename('foo')

will rename the file 'bar' to 'foo' on the system and leave 'bar' as a still-valid object that no longer points to a system file. Changing the return type of .rename() to return a new pathlib.PosixPath() object with path 'foo' could help reduce confusion about the behavior. For example:

bar_var = pathlib.PosixPath('bar')
foo_var = bar_var.rename('foo')

and foo_var would then be a pathlib.PosixPath() object pointing to 'foo'.

[brettcannon]

The idea in general seems reasonable. Anyone else have an opinion?

[serhiy-storchaka]

Path.rename() is simple wrapper around os.rename() and returns the result of os.rename(). If os.rename() became returning something useful, this change will made impossible to return it from Path.rename().

Why not create destination Path object explicitly?

    bar_var = pathlib.PosixPath('bar')
    foo_var = pathlib.PosixPath('foo')
    bar_var.rename(foo_var)

Note, that in 3.6 you can also write

    os.rename(bar_var, foo_var)

[WalterSzeliga]

If Path.rename() were made to be slightly more than a wrapper around os.rename(), then any future changes to the return value of os.rename() could be taken into consideration in the return value of Path.rename(). I don't see how anything would become impossible then.

Creating the destination Path object explicitly is my solution right now. Since it had become such a pattern in my code, I figured it could be delegated up to the level of the Path object and make for cleaner looking code.

[ukarroum]

It looks like the issue is now solved with: #13582