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! _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
