[Web-SIG] Re: Form field dictionaries

[David Fraser]

Steve Holden wrote:

>>-----Original Message-----
>>From: web-sig-bounces+sholden=holdenweb.com at python.org
>>[mailto:web-sig-bounces+sholden=holdenweb.com at python.org]On Behalf Of
>>Barry Warsaw
>>Sent: Friday, October 24, 2003 11:45 AM
>>To: Ian Bicking
>>Cc: web-sig at python.org
>>Subject: Re: [Web-SIG] Re: Form field dictionaries
>>
>>
>>On Fri, 2003-10-24 at 11:35, Ian Bicking wrote:
>>
>>    
>>
>>>I think this is already really decided -- if (and only if)
>>>      
>>>
>>there are
>>    
>>
>>>multiple values, then a list should appear in the output.
>>>      
>>>
>>I.e., {'a':
>>    
>>
>>>['1', '2']}.  This is how cgi works, and how almost all
>>>      
>>>
>>Python request
>>    
>>
>>>objects work.  When there's near-consensus in previous
>>>      
>>>
>>implementations,
>>    
>>
>>>I think we should keep the conventional behavior.  Plus, it
>>>      
>>>
>>means less
>>    
>>
>>>things to decide, which should make the design faster to create.
>>>      
>>>
>>I agree that it's basically decided, but I want to be clear in any
>>standard that we develop, exactly what the return types are in that
>>case, and/or how to test for one or the other.  E.g. you
>>can't use len()
>>because both lists and strings are sequences.  If the way to type test
>>the value is going to be "isinstance(val, list)", let's set that in
>>stone.
>>
>>Here's another alternative, if Python 2.2 is the minimal requirement
>>(and I think it should be, if not Python 2.3).  Return string and list
>>subclasses, which will act perfectly string-like and
>>list-like in those
>>contexts, but which support extended protocols.  See attached example.
>>
>>    
>>
>>>>>show(s)
>>>>>          
>>>>>
>>single value: hello
>>    
>>
>>>>>show(l)
>>>>>          
>>>>>
>>multi value: hello, world
>>
>>    
>>
>I've argued in the past that the correct approach is to determine in
>advance which fields can take multiple values, and reject multiple
>values for other fields as an error early in the form processing.
>
>The reason I say this is that it's annoying and inefficient to
>distinguish between a possibly-multi-valued field with only one value
>and a possibly-multi-valued field with multiple values.
>
>Here's an exerpt from a message I sent to ReportLab colleagues, and
>although it refers to a specific framework the intent should be obvious.
>The bottom line is that if a field *could* have multiple values I
>*always* want to see it as a list, even if the list only has a single
>member. And, of course, I *know* I'm right about this :-)
>  
>
Agreed, you should get a list, and only a list, if you want a list.
You should otherwise get a single value regardless.

>>def getCGIParams(*names):
>>    "returns dictionary of parameters found in the cgi script"
>>    dictionary = {}
>>    import cgi
>>    form = cgi.FieldStorage()
>>    for name in form.keys():
>>        value = form.getvalue(name)
>>        if isinstance(value, list):
>>            if name not in names:
>>                raise IllegalMultiValue
>>            dictionary[name] = [quoteValue(v) for v in value]
>>        else:
>>            if name in names:
>>                dictionary[name] = [quotevalue(value)]
>>            else:
>>                dictionary[name] = quotevalue(value)
>>    return dictionary
>>
>>This has the advantages that a) possibly-multi-valued arguments
>>are always represented as lists, and client code can use
>>len(arglist) to determine iteration count and subscripting
>>to select items, and b) we trap much earlier the case
>>where we see multiple values of arguments that are only
>>supposed to occur once.
>>
This kind of thing could be fairly simply implemented on top of the API, 
so the question is, is it common and important enough to be included, 
and what should be the syntax

David