[Web-SIG] wsgi.url_vars feedback
Phillip J. Eby
pje at telecommunity.com
Wed Nov 1 18:33:37 CET 2006
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
>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.)
More information about the Web-SIG