[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 symlinks (which resolves them before normalizing). -- components: Library (Lib) messages: 357534 nosy: iciocirlan priority: normal severity: normal status: open title: pathlib paths .normalize() type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 /= "../../../there"
>>> mypath
PurePosixPath('foo/../../../there')
>>> mypath = mypath.normalize()
>>> mypath
PurePosixPath('../../there')
>>> mypath /= "../../and/back/again"
>>> mypath
PurePosixPath('../../there/../../and/back/again')
>>> mypath = mypath.normalize()
>>> mypath
PurePosixPath('../../../and/back/again')
```
> I assume you want the same behaviour as os.path.normpath which already
> accepts a pathlike object to be added to pathlib.
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()`
vs. `mypath = PurePosixPath(normpath(mypath))`.
> Do note that Path inherits from PurePath, so providing a normalize() method
> on the latter means it will end up on the former.
That could be "circumvented" with a bit of code shuffling, e.g. moving
everything from `PurePath` to a `PathBase` or `_Path` or somesuch, and forking
the inheritance from there. On the other hand, it might be useful. I personally
can't think of a scenario, but the GNU folk certainly think so, see `realpath
--logical`:
https://www.gnu.org/software/coreutils/manual/html_node/realpath-invocation.html
--
___
Python tracker
<https://bugs.python.org/issue38924>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 function... It's broken by design if you use it to shoot yourself in the foot. If you want however to normalize an abstract path, an absolutely reasonable thing to do, it does the right and very useful thing. Because, well, the filesystem isn't the only thing that has paths and other things don't have symlinks. Also, this lib is called pathlib, not fspathlib, *and* someone had the foresight of separating filesystem paths from abstract paths. Quite a strange series of coincidences, no? Let me quote the initial comment for this issue, which apparently noone read: > On `PurePath` its usefulness is obvious, but it's debatable for `Path`, as it > would yield different results from `.resolve()` in case of symlinks (which > resolves them before normalizing). -- ___ Python tracker <https://bugs.python.org/issue38924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
