[Web-SIG] Form field dictionaries

David Fraser davidf at sjsoft.com
Mon Oct 27 02:45:11 EST 2003

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.


More information about the Web-SIG mailing list