Zbyszek Jędrzejewski-Szmek <zbys...@in.waw.pl> added the comment: > It doesn't make sense to "concatenate" one absolute path to another.
Please see the original description of the issue, or Serhiy's example. I was thinking about about a case where paths are resolved relative to a container root in a filesystem. Serhiy brings up the case of a web server which concatenates paths from one namespace (URLs) to paths from another (fs paths). > / has a simple explanation: if you start at /foo, and then do cd bar, you'll > end up in /foo/bar. But if you start at /foo, and then do cd /bar, you'll end > up in /bar. You are thinking about a user doing operations in a shell. The two cases described are precisely NOT like this. In both examples, no matter what the path is, it is not allowed to go above the "root of the namespace". I.e. if you start at "/foo", and concatenate "/bar", you end up in "/foo/bar". If you are looking up "https://example.com/some/path";, you want "/srv/www/some/path", etc. > what to do with C:\foo\bar, C:foo\bar, \\?\c\foo\bar, etc? I think that with those paths there is no solution. They already don't work in any reasonable way: >>> pathlib.Path('/asdf') / ("C:/some/path") >>> PosixPath('/asdf/C:/some/path') >>> pathlib.Path('C:\\asdf') / ("C:/some/path") >>> PosixPath('C:\\asdf/C:/some/path') Windows paths make no sense in the context of combination of namespaces and path concatenation, so I think it's fine to keep current behaviour (whatever it exactly is) for them. While the UNIX paths were designed to allow arbitrary nesting, the Windows paths were designed to always allow per-volume operations. The two concepts cannot be combined. > In any case you need to have some validation to disallow "..". Yes, that is a good point. In my code I do some validation that disallows ".." early on. But I think that the hypothetical //-operator should reject paths with "..". > But lstrip('/') works well here. It kind of does, but - it's rather verbose - it breaks the order, because it's on the right of the argument. I'll write to python-ideas. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44452> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
