Unordered query params and URL.__eq__

[bsolomon1124]

I did not want to file this as a bug because the yarl authors are the URL experts and I most certainly am not. This is more of a question, less of a bug.

I've noticed that two URL with what would seem to be semantically equal query strings compare not-equal.

>>> from yarl import URL
>>> f = URL("https://foo.com/bar?a=1&b=2")
>>> g = URL("https://foo.com/bar?b=2&a=1")
>>> f == g
False

>>> f.query
<MultiDictProxy('a': '1', 'b': '2')>
>>> f.query == g.query
False
>>> sorted(f.query.items()) == sorted(g.query.items())
True

I could not find a note in rfc3986 one way or the other regarding if "differently-ordered but otherwise equal" query parameters should be compared. I'm curious if yarl is following any explicit guidance that I've missed.

In the case of URL.__eq__, these two compare as not equal since __eq__ ends up comparing f._val and g._val, which uses the raw SplitResult.query.

[asvetlov]

The strict comparison rule is: URLs are equal if their string representations are equal.
The relaxed rule applies string representation equality to normalized URL (the normalization procedure is not strictly specified by RCF but still we can have an informal consensus here).
Query params reordering is unlikely a subject for URL normalization in any sense. Moreover, it can change the server behavior easily. That's why YARL processes such URLs as different objects.

If in your particular case the query parameters order doesn't matter, you can use a hand-written url_cmp(url1, url2) function that does what do you want, the sorting url.query by keys including.