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