Hi Mart
'http://example.com/a/b/c?a=b&b=d&foo=%2Fbar <http://example.com/a/b/c?a=b&b=d&foo=%2Fbar>'
Duplicates are discarded:
Why discard duplicates? They are valid and have a well-defined meaning.
The bad thing about reasoning about query strings is that there is no comprehensive documentation about their meaning. Both RFC 1738 and RFC 3986 are rather vague in that matter. But I agree that duplicates actually have a meaning (an ordered list of identical values), so I'll remove the bits that prune them unless anyone opposes (which I doubt).
But if a value is given, the empty key is considered a duplicate (i.e. the
case of a&a=b is considered nonsensical):
Again, it is a valid url and this will change its meaning. Why?
I'm uncertain whether a&a=b has a meaning, but don't see any harm in supporting it, so I'll add the feature.
'http://example.com/a/b/c?a=b&c <http://example.com/a/b/c?a=b&c>'
If you need to pass in key names that are not allowed in keyword arguments,
pass them via a dictionary in second argument:
>>> add_query_params('foo', {"+'|äüö": 'bar'})
'foo?%2B%27%7C%C3%A4%C3%BC%C3%B6=bar'
Order of original parameters is retained, although similar keys are grouped
together.
Why the grouping? Is it a side effect of your desire to discard duplicates? Changing the order like that changes the meaning of the url. A concrete case where the order of field names matters is the ":records" converter in http://pypi.python.org/pypi/zope.httpform/1.0.1 (a small independent package extracted from the form handling code in zope).
It's also related to duplicate handling, but it mostly relates to the data structure used in the initial implementation (an OrderedDict). Re-grouping is removed now and not having to deal with duplicates simplified the code considerably (using a simple list of key-value tuples now).
If you change it to keep duplicates and not unnecessarily mangle the field order I am +1, else I am -0.