[Web-SIG] Re: Form field dictionaries

[Steve Holden]

> -----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 :-)

> 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.

regards
--
Steve Holden          +1 703 278 8281        http://www.holdenweb.com/
Improve the Internet           http://vancouver-webpages.com/CacheNow/
Python Web Programming                http://pydish.holdenweb.com/pwp/
Interview with GvR August 14, 2003       http://www.onlamp.com/python/