[Web-SIG] wsgi.url_vars feedback

[Phillip J. Eby]

At 11:10 AM 11/1/2006 -0600, Ian Bicking wrote:
>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").

routing_args is fine by me; its *purpose* is much more "discoverable" than 
url_vars is.  When I see url_vars I think that maybe it's a collection of 
CGI vars related to the URL, like PATH_INFO, SCRIPT_NAME, etc.!


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

Yep, that was my reasoning; I think its most valuable use is as arguments 
to a callable, such that a dispatcher or routing system would just invoke a 
callable with some framework-defined arguments, combined with the * and ** 
from the routing arguments.

Of course, at that point it becomes pretty clear that the thing doing the 
routing and the thing being called are part of the same framework anyway, 
and there's no real point to having the spec, but oh well.  :)  (Not that 
there aren't still *some* cross-framework use cases for this spec, but they 
seem a bit obscure to me.)