[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Change by Brett Cannon : -- assignee: brett.cannon -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Brett Cannon added the comment: So I tried making pathlib.PurePath handle "." more like ".." and tests started failing all over the place in test_pathlib, which means it would be a change in semantics and could start silently breaking people as most of the checks are for specific exceptions.

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Jeffrey Kintscher added the comment: I'll take a crack at adding support for Path('.').name == '.'. -- ___ Python tracker ___ ___ P

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Brett Cannon added the comment: Anyone up for doing a PR that makes Path('.').name == '.'? It would be good to see if that would break the stdlib as a proxy as to how many people might be relying on these semantics. My hope is nothing breaks in which case we can make the change in 3.9 and no

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Steinmann added the comment: @Brett: I also think making Path('.').name evaluate to '.' would be the most logical thing. More even so since the documentation says PurePath.name() is equivalent to os.path.basename()[1], but: >>> Path('.').name '' >>> os.path.basename('.') '.' Though I'm not

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Brett Cannon added the comment: Thinking about this a bit, I my gut says having Path('.').name == '.' makes more sense than returning ''. My reasoning is that in any case where there's a single value -- e.g. Path('spam') -- you end up with the part returned in `name`. That suggests to me tha

[issue37130] pathlib.Path.with_name() handles '.' and '..' inconsistently

Brett Cannon added the comment: @Antoine: Basically Path.with_name() fails under '.' but works with '..' although with a somewhat odd result. And then after that is the fact that Path('.').name is the empty string but for Path('..').name it's '..' (which is what causes Path('.').with_name()