[Web-SIG] Form field dictionaries

[David Fraser]

Ian Bicking wrote:

> On Friday, October 24, 2003, at 01:00 PM, David Fraser wrote:
>
>> Ian Bicking wrote:
>>
>>> Every time I have encountered an unexpected list it has been because 
>>> of a bug somewhere else in my code.  I might use a getone() method 
>>> that threw some exception when a list was encountered, but I'd 
>>> *never* want to use getfirst().  getfirst() is sloppy programming.  
>>> (getlist() is perfectly fine though)
>>
>>
>> There seems to be a lot of agreement on this...
>> So let's take it that the interface will be a dictionary, with an 
>> extra method defined, getlist, which will return multiple items if 
>> multiple items were defined, or a list containing a single item 
>> otherwise.
>
>
> Additionally, getlist should return the empty list if the key isn't 
> found, as this follows naturally (but a KeyError for normal access 
> when a value isn't found).  I also think cgi's default of throwing 
> away empty fields should not be supported, even optionally.
>
> But I haven't really heard reaction to the idea that you get a 
> BadRequest or other exception if you try to get key that has multiple 
> values.  Throwing information away is bad, and unPythonic (though very 
> PHPish).  I don't think we should copy PHP here.  I have *never* 
> encountered a situation where throwing away extra values found in the 
> query is the correct solution.  Either the form that is doing the 
> submission has a bug, or else the script needs to figure out some 
> (explicit!) way to handle the ambiguity.

What about comparing multiple values to see if they're the same. I don't 
see throwing values away as such a bad problem...

> We also need a way to get at the raw values.  I suppose you could do:
>
> fields = {}
> for key in req.fields.items():
>     v = req.getlist(key)
>     if len(v) == 1: fields[key] = v[0]
>     else: fields[key] = v
>
> But that's kind of annoying, since the request object probably 
> contains this kind of dictionary already.  This will be required for 
> backward compatibility, if we want this request to be wrapped to 
> support existing request interfaces.

I think the correct solution is to be explicit about the keys you want 
lists for ... as this would have to be coded explicitly somewhere in the 
code anyway.

David