Steve:
I'm darned if I know. I simply know that it isn't right for http resources.
/F:
the URI specification disagrees; an URI that starts with "../" is per- fectly legal, and the specification explicitly states how it should be interpreted.
I have looked at the spec, and can't figure out how its explanation matches the observed urljoin results. Steve's excerpt trimmed out the strangest example.
urlparse.urljoin("http://blah.com/a/b/c", "../../../") 'http://blah.com/../' urlparse.urljoin("http://blah.com/a/b/c", "../../../..") # What?! 'http://blah.com/' urlparse.urljoin("http://blah.com/a/b/c", "../../../../") 'http://blah.com/../../'
(it's important to realize that "urijoin" produces equivalent URI:s, not file names)
Both, though, are "paths". The OP, Mik Orr, wrote: I agree that supporting non-filesystem directories (zip files, CSV/Subversion sandboxes, URLs) would be nice, but we already have a big enough project without that. What constraints should a Path object keep in mind in order to be forward-compatible with this? Is the answer therefore that URLs and URI behaviour should not place constraints on a Path object becuse they are sufficiently dissimilar from file-system paths? Do these other non-FS hierarchical structures have similar differences causing a semantic mismatch? Andrew dalke@dalkescientific.com