[issue38924] pathlib paths .normalize()

Brett Cannon added the comment: While I understand you're disappointed, do realize that the tone of your response isn't necessary. I'm going to assume you didn't mean for it to come off as confrontational and still provide a reply. > you do realise there are no symlinks to resolve on

[issue38924] pathlib paths .normalize()

Ionuț Ciocîrlan added the comment: Brett and Serhiy, you do realise there are no symlinks to resolve on PurePaths, right? > os.path.normpath() is broken by design. Why don't you deprecate it then? Sounds like the reasonable thing to do, no? So many innocent souls endangered by this evil

[issue38924] pathlib paths .normalize()

Brett Cannon added the comment: I'm going with Serhiy's recommendation and closing this. Sorry, Ionuț. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue38924] pathlib paths .normalize()

Serhiy Storchaka added the comment: There were reasons why something like PurePath.normalize() was not added at first place. os.path.normpath() is broken by design. It does not work as you expect in case when the .. component is preceeded by a symlink. Its behvior can lead to bugs and maybe

[issue38924] pathlib paths .normalize()

Brett Cannon added the comment: > From my experience in the past the intention has been to keep the API minimal Correct, all of os.path and shutils does not need to end up in pathlib. :) Hence why the request to add things is always tough as we have to try and strike a balance of useful but

[issue38924] pathlib paths .normalize()

Vedran Čačić added the comment: I think the real issue here > mypath = PurePosixPath(normpath(mypath)) is the PurePosixPath wrapper. It is nice that normpath _accepts_ pathlike objects, but it should then not return a generic str. It should try to return an object of the same type. Of

[issue38924] pathlib paths .normalize()

Karthikeyan Singaravelan added the comment: > Yes, exactly the same behaviour, but arguing that normpath() can take a > pathlib object is just saying that it saves you from doing an intermediate > str(), which is, well, nice, but still not pretty. Consider `mypath = > mypath.normalize()`

[issue38924] pathlib paths .normalize()

Ionuț Ciocîrlan added the comment: > Can you please add an example of how normalize() should behave? ``` >>> mypath = PurePosixPath("foo/bar/bzz") >>> mypath /= "../../" >>> mypath PurePosixPath('foo/bar/bzz/../..') >>> mypath = mypath.normalize() >>> mypath PurePosixPath('foo') >>> mypath /=

[issue38924] pathlib paths .normalize()

Brett Cannon added the comment: Do note that Path inherits from PurePath, so providing a normalize() method on the latter means it will end up on the former. -- nosy: +brett.cannon ___ Python tracker

[issue38924] pathlib paths .normalize()

Karthikeyan Singaravelan added the comment: Can you please add an example of how normalize() should behave? I assume you want the same behaviour as os.path.normpath which already accepts a pathlike object to be added to pathlib. -- nosy: +xtreak

[issue38924] pathlib paths .normalize()

New submission from Ionuț Ciocîrlan : pathlib paths should expose a `.normalize()` method. This is highly useful, especially in web-related scenarios. On `PurePath` its usefulness is obvious, but it's debatable for `Path`, as it would yield different results from `.resolve()` in case of