homepage

Docstring for urlunparse says:
 """Put a parsed URI back together again. This may result in a
 slightly different, but equivalent URI, if the URI that was parsed
 originally had redundant delimiters, e.g. a ? with an empty query
 (the draft states that these are equivalent)."""
"Draft" here refers to RFC 1808, superseded by 3986. However, RFC 3986
(section 6.2.3) states:
"Normalization should not remove delimiters when their associated
component is empty unless licensed to do so by the scheme 
specification. For example, the URI "http://example.com/?" cannot be 
 assumed to be equivalent to any of the examples above. Likewise, the 
 presence or absence of delimiters within a userinfo subcomponent is 
 usually significant to its interpretation. The fragment component is 
 not subject to any scheme-based normalization; thus, two URIs that 
differ only by the suffix "#" are considered different regardless of 
the scheme."
I guess we need some tests here to check compliance.

This is indeed a bug. urlunparse should special-case "#" so as not to
discard it.

Currently this claim will fail:
>>> obj = urlparse.urlparse('http://a/b/c?')
>>> urlparse.urlunparse(obj)
'http://a/b/c'
>>> obj = urlparse.urlparse('http://a/b/c#')
>>> urlparse.urlunparse(obj)
'http://a/b/c'
If we move away from the current behavior, there will surely be some test failures that can be observed for urljoins. We will have to consider those cases too while fixing this.

Slipped under the radar guys?

In order to fix this, I think ParseResult needs to have two additional fields, indicating with an empty prefix or query string are used.
Both ParseResult.fragment and ParseResult.query omit the leading '#' or '?' from their value. This makes it impossible to determine if the fragment/query string is entirely absent, or has no value.

Looks like this duplicates Issue 22852, which has a patch, although its author had second thoughts on the implementation