[Web-SIG] Proposal: wsgi.url_vars

[Ian Bicking]

Christopher Lenz wrote:
> Am 21.10.2006 um 19:49 schrieb Ian Bicking:
>> If a dispatcher (like `routes <http://routes.groovie.org/>`_ or
>> `selector <http://lukearno.com/projects/selector/>`_) pulls named
>> information out of the portion of the request path it parses, it  
>> can put
>> that information into a dictionary in ``environ['wsgi.url_vars']``.
> 
> While I think this is a great idea in general, I don't like that this  
> is limited to "named information".
 >
> In the kind of dispatching I normally use, there's only one or maybe  
> two parts of the URL that I want to receive as parameters. I like  
> saving the overhead of making those named groups in regexes, and  
> instead just use unnamed groups as positional arguments.
> 
> So not supporting both positional and named arguments limits the  
> usefulness of this specification IMHO. How about making  
> 'wsgi.url_vars' a tuple of the form "(args, kwargs)" (the first a  
> list or tuple, the second a dict)?

Hmm... so, a few things occur to me:

1. The dictionary could have integer keys like {1: arg1, 2: arg2}.  This 
is hard to unpack.  Eh, not a good idea I guess.

2. We use (args, kwargs).  Frameworks can probably handle this just 
fine.  Quite a few systems can't produce positional arguments, but that 
probably doesn't matter -- at least the end result is something like a 
Python function call, then there's usually a named equivalent to 
positional arguments.  When it is exposed directly to the application it 
seems a little more awkward.  For instance, I was thinking I'd add a 
req.url_vars to the request object that's just a proxy to 
environ['wsgi.url_vars'].  But having that return a tuple isn't very 
convenient.  I guess it could be req.url_vars and req.url_args, or 
something like that.  It adds to the complexity some.

3. Anything can go under *some* name, so you could do {'args': 
(positional args)}.  You'd still have to do a bit of unpacking if you 
had both positional and keyword arguments, but it would be fairly 
simple.  We could come up with a convention for this that we document in 
the spec.


I guess I didn't mention it in the spec, but I assumed that the 
dictionary would have only string keys (though I don't know if it 
matters), but the values could be of any type.  E.g., 
/archive/2005/10/01 could create {'date': date(2005, 10, 1)}.


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