[Web-SIG] wsgi.url_vars feedback

[Ian Bicking]

Phillip J. Eby wrote:
> At 05:42 PM 10/31/2006 -0600, Ian Bicking wrote:
>> Phillip J. Eby wrote:
>>> At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
>>>> 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.)
> 
> That would actually be another reason *not* to use "vars", because these 
> aren't the same things.  They're something that's framework-specific, 
> not part of the nature of HTTP.  I would actually suggest that 
> url_params would be better, except that URLs *do* have something called 
> parameters.
> 
> If you *must* have vars, please call it wsgi.routing_vars or 
> wsgi.dispatch_vars instead, so at least it will be clearly 
> distinguishable from other URL variables.  In fact, 
> wsgi.dispatch_arguments would probably be the *most* descriptive name 
> for what these actually are.  Note that there isn't any requirement here 
> that the data even comes from the URL!

I don't really care that much, somehow url_vars just seemed the most 
natural choice and I hardly even thought about it.  Of course "URLs" 
don't even exist (though I'm still fuzzy on why), so obviously the 
terminology is a bit crude.  And really this is typically from the path, 
not the entire URL.

Probably the name I like the most of what you've suggested would be 
"wsgi.routing_args", since that makes me think of "things that were 
captured on the way here" ("routing" more so than "dispatch"). 
Actually, I don't really feel any strong difference between args and 
vars, though I suppose now that it's a tuple of positional and named 
values then "args" makes more sense.

This would break Luke's quick implementation, but hopefully he won't 
mind.  It hasn't been moved to "accepted" yet, so he was warned ;)

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