[Web-SIG] wsgi.url_vars feedback

[Ian Bicking]

Phillip J. Eby wrote:
> At 05:39 PM 10/23/2006 -0500, Ian Bicking wrote:
>> By using a tuple or list, you can be sure you don't have a sparse list,
>> which probably isn't something any system is likely to handle.  The
>> double underscores kind of mark __args__ as a special kind of key, so
>> it's less likely to overlap with a simple named key.  Removing it from
>> the dict or handling it is special; you don't have to look at all the
>> keys to see if any are ints, you just test "'__args__' in url_vars".
>>
>> Would this satisfy everyone?
> 
> Call it "wsgi.url_args", and make it a two-item tuple: *args, **kw.  
> That's far simpler than any of the wacky encodings proposed so far, and 
> can be used to invoke a function directly, e.g.:
> 
>     apply(f, *environ['wsgi.url_args'])
> 
> or, less cleverly (i.e. more readably):
> 
>     args, kw = environ['wsgi.url_args']
>     f(*args, **kw)

Having thought about it, I think storing a tuple of (args, kwargs) is 
the best way to do this, since it's most explicit.  Consumers can deal 
with args specially, ignore them, or raise an error, as they see fit -- 
there are reasons to do each of these.  Hiding args in kwargs makes this 
choice more implicit, and probably more error prone as a result.

One little question: if a dispatcher can never produce one of the kinds 
of information (which happens for some of them), should they put in an 
empty list/tuple or empty dict, or should they put in None for that 
item?  I'm currently saying they must put in a list/tuple or dict.

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?


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