-1 on doing this from me.

While I don't see it hurting anything when "type(query) is dict" I'd much rather encourage people to write better tests that do not take the lazy way out.  Tests that get by comparing a generated string to a "golden" string are soo often wrong because the golden string is not what they actually wanted to test. Instead the author meant to test the meaning of the result rather than the specific incantation of it that they pasted in their code for an assertEqual check.

(This does suggest that some additional unittest methods to make comparing common things like this in a safe manner would be useful to people. urls, html and xml with attributes, json, etc)

Ex: We've run into many tests that were failing due to hash randomization because they compared json strings... rather than suggest that json.dumps sort dictionaries before generating output, having the tests use json.loads and compare the actual data structure rather than a golden value string is much better.

If a change like this is made, it needs to be conditional in 2.7 and 3.2 to only sort when hash randomization is enabled to avoid altering the existing behavior of urlencode for the default PYTHONHASHSEED=0 case on 2.7 and 3.2.

As far as this being an enhancement rather than a bugfix... I sort of agree that this is an enhancement.  And if this is an enhancement, we don't need to do it at all: People will already have done the right thing making their code work with 3.3's hash randomization by default before long before 3.4 is out.