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
[EMAIL PROTECTED]
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
