[Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
steven.bethard at gmail.com
Tue Apr 14 03:19:27 CEST 2009
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa <mrts.pydev at gmail.com> wrote:
> 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:
>> > 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.
I believe the usual Python approach here is to have two variants of
the function, add_query_params and add_query_params_no_dups (or
whatever you want to name them). That way the flag parameter is
"named" right in the function name.
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
More information about the Python-Dev