On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard <steven.beth...@gmail.com> wrote: > > On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa <mrts.py...@gmail.com> wrote: > > > > > > On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou <solip...@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 arguments generally. 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) 'http://example.com/?a&b=c&d=None' However, 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 should work.) 2) the API gets overly complicated -- as per the complaint above, it's usability-challenged already. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com