On 14/05/2014 21:12, quoth Rob Stewart:
In the event that the provided path cannot be made relative to base, isn't it more generically useful to return the original unmodified absolute path? (ie. simply returning p instead of throwing, at least when both paths are absolute.)
This gets you into the discussion of error codes versus exceptions as a means to report errors.
Not really; I was asking if this case should be considered as an error at all. I can see a fairly likely use case of "translate this absolute path to one that is relative to my current working dir", for which sometimes a perfectly acceptable answer is "the original absolute path".
Although that brings up another question (which I'm not really familiar enough with the "path" class internals to answer by looking at the example implementation): is "base" intended to be assumed as a directory name (which is how most filesystem "make relative" functions typically work) or as a file name (which is how URL "make relative" works)?
path makes no assumptions about what it references, or whether the pathname even exists in the filesystem.
I'm aware of that; my point was that the semantics of the "make a relative path" operation typically differ between filesystems and URLs. For example (imagining some hypothetical functions): make_relative_uri("http://foo.com/baz/bar", "http://foo.com/baz") == "baz/bar" make_relative_uri("http://foo.com/baz/bar", "http://foo.com/baz/") == "bar" make_relative_path("/baz/bar", "/baz") == "bar" make_relative_path("/baz/bar", "/baz/") == "bar" Essentially, URLs always assume any trailing component that does not end in a slash is a filename, and will make paths relative to the containing directory of that file. While filesystems generally assume that the base is a directory name regardless of whether it has a trailing slash or not.