classification
Title: pathlib strips trailing slash
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.4, Python 3.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, akuchling, h.venev, icordasc, ischwabacher, pitrou, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2014-03-23 13:55 by h.venev, last changed 2015-04-14 16:54 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
pathlib.patch h.venev, 2014-03-23 13:55 patch review
Messages (15)
msg214581 - (view) Author: Hristo Venev (h.venev) * Date: 2014-03-23 13:55
Some programs' behavior is different depending on whether the path has a trailing slash or not. Examples include ls, cp, mv, ln, rm and rsync. URL paths may also behave differently. For example http://xkcd.com/1 redirects to http://xkcd.com/1/

Boost.Filesystem's path class also supports trailing slashes in paths. C++'s filesystem library proposal is also based on Boost.Filesystem.
msg214594 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-23 16:05
Yes, this is by design. The occasional difference between slash-ended and non-slash-ended paths is unexpected and potentially confusing. Moreover, it's not a property of the OS itself - it's just some syntactic sugar to enable an option such as resolving symlinks. pathlib paths represent filesystem paths, not arbitrary shell arguments.

Similarly, pathlib doesn't have special processing for "~someuser" parts.

(as for URL paths, they are not part of the design space of pathlib)
msg214595 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-23 16:06
Closing as rejected, sorry.
msg214596 - (view) Author: Hristo Venev (h.venev) * Date: 2014-03-23 16:14
What about OpenVMS?
msg214597 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-23 16:15
Can you elaborate? Python hasn't supported VMS for quite some time...
msg214598 - (view) Author: Hristo Venev (h.venev) * Date: 2014-03-23 16:19
AFAIK paths on OpenVMS are represented in a strange way. [dir.subdir]filename is a path for a file and [dir.subdir.anothersubdir] is a path for a directory.
msg214599 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-23 16:20
Then I'm afraid the current Path classes won't do a good job of representing them :-)

But as I said, Python probably doesn't run on VMS anymore, so this is a rather theoretical problem. Maybe if some day Python supports VMS again, someone can contribute a VMSPath implementation.
msg214600 - (view) Author: Hristo Venev (h.venev) * Date: 2014-03-23 16:21
Or maybe URLPath?
msg214601 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-23 16:22
> Or maybe URLPath?

I'm skeptical about that. I think someone should first prototype a
PureURLPath and maybe publish it on PyPI.
(as for the non-pure variant, URLPath, it doesn't seem to make sense)
msg214604 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 16:47
PEP11 states that VMS was unsupported in 3.3.  Code was removed from 3.4 via #16136.
msg224889 - (view) Author: Isaac Schwabacher (ischwabacher) * Date: 2014-08-05 21:10
This may be only syntactic sugar, but it is POSIX-specified syntactic sugar: according to http://pubs.opengroup.org/onlinepubs/9699919799/. trailing slashes in pathnames are semantically meaningful in pathname resolution.  Tilde escapes are not mentioned.

4.12 Pathname Resolution
========================

[...]

A pathname that contains at least one non- <slash> character and that ends with one or more trailing <slash> characters shall not be resolved successfully unless the last pathname component before the trailing <slash> characters names an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved. Interfaces using pathname resolution may specify additional constraints[1] when a pathname that does not name an existing directory contains at least one non- <slash> character and contains one or more trailing <slash> characters.

If a symbolic link is encountered during pathname resolution, the behavior shall depend on whether the pathname component is at the end of the pathname and on the function being performed. If all of the following are true, then pathname resolution is complete:

    1. This is the last pathname component of the pathname.

    2. The pathname has no trailing <slash>.

    3. The function is required to act on the symbolic link itself, or certain arguments direct that the function act on the symbolic link itself.

In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link. [...]
msg224942 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-08-06 15:46
Isaac, thanks for the reference. I'm reopening the issue for discussion (although I'm still not convinced this would be actually a good thing).
May I ask you to post on the python-dev mailing-list for further feedback?
msg240930 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2015-04-14 16:15
The general mood on python-dev seemed to be that the trailing slash shouldn't be normalized.  Can this still be fixed, or is it too late since pathlib was shipped in 3.4?

The python-dev discussion was at https://mail.python.org/pipermail/python-dev/2014-August/135670.html
msg240947 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-14 16:54
I beg to disagree :) Pathlib tries to find a compromise between user-friendliness and power, but it's definitely more on the user-friendliness side than, say, the os module APIs. In other words, I don't think it's a problem if not all details of OS semantics can be encoded in Path objects. In practice, the situations where it's useful to make a difference between a slash-ending path and a non-slash-ending path are few and far between.

There are all kinds of small API decisions which have to be revisited if we allow trailing slashes to be significant. For example, what should be the last component of the path? The component just before the ending slash, or the empty string? What if slice off the last part? What is the name, stem, suffix? etc.

A path, conceptually, is just that: a sequence of names designating the nodes in the filesystem tree that you walk to get to the terminal node. If you start making trailing slash significants then this simple, intuitive abstraction breaks and things become much more awkward to understand.
msg240948 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-14 16:54
Therefore, I'm finally closing this as won't fix :)
History
Date User Action Args
2015-04-14 16:54:25pitrousetstatus: open -> closed
resolution: wont fix
messages: + msg240948
2015-04-14 16:54:06pitrousetmessages: + msg240947
2015-04-14 16:15:57akuchlingsetnosy: + akuchling
messages: + msg240930
2014-08-08 19:00:14icordascsetnosy: + icordasc
2014-08-06 15:57:32serhiy.storchakasetnosy: + serhiy.storchaka

type: behavior
resolution: rejected -> (no value)
versions: + Python 3.5
2014-08-06 15:46:21pitrousetstatus: closed -> open

messages: + msg224942
2014-08-05 21:10:11ischwabachersetnosy: + ischwabacher
messages: + msg224889
2014-03-23 16:47:48BreamoreBoysetnosy: + BreamoreBoy
messages: + msg214604
2014-03-23 16:22:59pitrousetmessages: + msg214601
2014-03-23 16:21:48h.venevsetmessages: + msg214600
2014-03-23 16:20:36pitrousetmessages: + msg214599
2014-03-23 16:19:02h.venevsetmessages: + msg214598
2014-03-23 16:15:25pitrousetmessages: + msg214597
2014-03-23 16:14:30h.venevsetmessages: + msg214596
2014-03-23 16:06:18pitrousetstatus: open -> closed
resolution: rejected
messages: + msg214595
2014-03-23 16:05:33pitrousetnosy: + pitrou
messages: + msg214594
2014-03-23 13:55:56h.venevcreate