Hi, this is a proposed patch to add global functions for accessing values from (in particular) request.vars and friends (any dictionary-like object will work) in a way that (safely) satisfies the assumption that the input vars for a given key are either singletons or lists.
The functions are rather simple: Given the request: /a/b/c?x=abc getfirst(request.vars, 'x') -> 'abc' getlast(request.vars, 'x') -> 'abc' getall(request.vars, 'x') -> ['abc'] Given the request: /a/b/c?x=abc&x=def getfirst(request.vars, 'x') -> 'abc' getlast(request.vars, 'x') -> 'def' getall(request.vars, 'x') -> ['abc', 'def'] getall(request.vars, 'y') -> None getall(request.vars, 'y') or [] -> [] If there is anything like this already, I certainly will retract my suggestion. The potentially controversial parts are that the functions are defined in gluon.utils (I couldn't find a more logical place to put them, and it makes no difference to me where they end up), and they're loaded into the request environment, just like the html helpers. Patch can be found at: http://pastebin.com/g6Vs9PrU Background/motivation: This function group is inspired by the behavior of <http:// pythonpaste.org/webob/reference.html#query-post-variables> and similar functionality that other frameworks provide, and would be particularly useful in cases where the client-side code is not managed by something like web2py's FORM interface -- as of version 1.83.2, web2py prepares a Storage instance such that: /a/b/c?x=5 -> request.vars.x == '5' /a/b/c?x=5&x=abc -> request.vars.x == ['5', 'abc'] This could lead to naive code like the following to fail with some simple request fakery: if request.vars.search.upper().startswith('FUZZY'): pass # some real code here It's possible that this kind of fakery could also lead to many of the web2py validators failing in common cases (though I haven't looked into that much). However, it is often allowable that the first (or last) value passed is authoritative, leading to a more robust system.
