Demian Brecht added the comment:
> The current behaviour when no scheme is present is fairly sensible to me and
> should not be changed to do string concatenation nor raise an exception
Agreed. Defaulting to relative behaviour makes sense as I imagine that'll be
the general use case.
> I removed the gopher, wais, and imap schemes from the list
I'd be concerned about removing items as non_hierarchical /is/ public facing
and it's reasonable to assume that there are libraries out there that depend on
these. Additionally, at a glance through their respective RFCs, it seems that
these three protocols /do/ belong in the non_hierarchical list. While WAIS and
IMAP do use / as a delimiter, they're not hierarchical and therefore relative
joining doesn't make sense. For example, with the following definition in mind
(RFC4156):
wais://<host>:<port>/<database>/<wtype>/<wpath>
The following will result in an incorrect URL:
urljoin('wais://f...@bar.com/mydb/type/path', '/newpath')
> However I am still not really convinced that my first urljoin-scheme.patch is
> a bad idea. Do people actually use urljoin() with these schemes like mailto
> in the first place?
I'd be inclined to agree that it's far from common practice. That said, I did
find one instance of a project that seems to depend on current behaviour
(although it's only in tests and I haven't looked any deeper):
https://github.com/chfoo/wpull/blob/32837d7c5614d7f90b8242e1fbb41f8da9bc7ce7/wpull/url_test.py#L637.
I imagine that the current behaviour may possibly be useful for utilities such
as web crawlers. In light of that and the fact that the urllib.parse docs
currently has a list of protocols that are intended to be supported across the
entire module's API, I think that it's important to not break backwards
compatibility in cases where the relative URL would have been returned. Your
second patch seems to have this behaviour which I think is preferable.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
