[Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
mrts.pydev at gmail.com
Mon Apr 13 22:14:50 CEST 2009
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa <mrts.pydev at gmail.com> wrote:
> > On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou <solipsis at pitrou.net>
> > wrote:
> >> Mart Sõmermaa <mrts.pydev <at> gmail.com> writes:
> >> >
> >> > Proposal: add add_query_params() for appending query parameters to an
> >> > URL to
> >> urllib.parse and urlparse.
> >> Is there anything to /remove/ a query parameter?
> > I'd say this is outside the scope of add_query_params().
> > As for the duplicate handling, I've implemented a threefold strategy that
> > should address all use cases raised before:
> > def add_query_params(*args, **kwargs):
> > """
> > add_query_parms(url, [allow_dups, [args_dict, [separator]]], **kwargs)
> > Appends query parameters to an URL and returns the result.
> > :param url: the URL to update, a string.
> > :param allow_dups: if
> > * True: plainly append new parameters, allowing all duplicates
> > (default),
> > * False: disallow duplicates in values and regroup keys so that
> > different values for the same key are adjacent,
> > * None: disallow duplicates in keys -- each key can have a single
> > value and later values override the value (like dict.update()).
> Unnamed flag parameters are unfriendly to the reader. If I see something like:
> add_query_params(url, True, dict(a=b, c=d))
> I can pretty much guess what the first and third arguments are, but I
> have no clue for the second. Even if I have read the documentation
> before, I may not remember whether the middle argument is "allow_dups"
> or "keep_dups".
Keyword arguments are already used for specifying the arguments to the
query, so naming can't be used. Someone may need an 'allow_dups' key
in their query and forget to pass it in params_dict.
A default behaviour should be found that works according to most
user's expectations so that they don't need to use the positional
Antoine Pitrou wrote:
> You could e.g. rename the function to update_query_params() and decide that
> every parameter whose specified value is None must atcually be removed from
> the URL.
I agree that removing parameters is useful. Currently, None is used
for signifying a key with no value. Instead, booleans could be used:
if a key is True (but obviously not any other value that evaluates to
True), it is a key with no value, if False (under the same evaluation
restriction), it should be removed from the query if present. None
should not be treated specially under that scheme. As an example:
>>> update_query_params('http://example.com/?q=foo', q=False, a=True, b='c', d=None)
1) I'm not sure about the implications of 'foo is True', I have never
used it and PEP 8 explicitly warns against it -- does it work
consistently across different Python implementations? (Assuming on the
grounds that True should be a singleton no different from None that it
2) the API gets overly complicated -- as per the complaint above, it's
More information about the Python-Dev