[Web-SIG] wsgi.url_vars feedback

[Ian Bicking]

Phillip J. Eby wrote:
> At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
>> One little question: if a dispatcher can never produce one of the 
>> kinds of information (which happens for some of them), should they put 
>> in an empty list/tuple or empty dict, or should they put in None for 
>> that item?  I'm currently saying they must put in a list/tuple or dict.
> 
> This is the correct choice, IMO.  I think the spec should be explicit, 
> however, that these values should be usable with * and ** (or apply()), 
> as that will help clarify the meaning/rationale of the values.

Sure; I've said list/tuple and dict in the spec, but I don't know if 
there's a reason to be quite as strict as WSGI in the types.

*args is fairly flexible, anything that can be coerced to a tuple seems 
to work.  **kwargs is more picky -- the keys must be strings (which I've 
mentioned, but not very strictly) and it must be a dict object 
(dict-like objects are not accepted, which I don't quite understand).

I suppose I should say that; or conversely the spec should specifically 
tell consumers to use **dict(kwargs) to guard against dict-like objects. 
  Anyway, I'll just go with **-safe.


>> Anyway, I've updated the spec:
>>
>> http://wsgi.org/wsgi/Specifications/url_vars
>> http://wsgi.org/wsgi/Specifications/url_vars?action=diff
>>
>> Is everyone happy with this version?
> 
> I still think it should be url_args rather than url_vars -- I don't see 
> any reason why they could be considered "variables" rather than 
> arguments.  :)  But other than that, and the desire to see clarification 
> about */** as an intended/supported use case, I give it a +1.

I was thinking about variables similar to GET and POST variables, which 
seems to be the most common way to refer to them.  (Of course GET 
variables are actually query string variables, which is orthogonal to 
the request method, but so it goes.)


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org