[Web-SIG] wsgi.url_vars feedback

[Ian Bicking]

Simon Willison wrote:
> I've spotted a potential problem with your wsgi.url_vars specification 
> suggestion.
> 
> http://wsgi.org/wsgi/Specifications/url_vars
> 
> The spec calls for wsgi.url_vars to refer to a dictionary. In Django, we 
> originally required named captures in regular expressions - but 
> eventually realised that for many cases just having positional captures 
> was less work for developers and worked just as well. Here's some code I 
> wrote today:
> 
>     (r'^archive/(\d+)/(\d+)/(\d+)/(\w+)/$', blog.entry),
> 
> def entry(request, year, month, day, slug):
>     # ...
> 
> This form of URL variable extraction does not appear to be covered by 
> your wsgi.url_vars spec. One solution could be to extend the spec to 
> suggest using integer keys to represent this case?
> 
> environ['wsgi.url_vars'] = { 1: '2006', 2: '06', 3: '12', 4: 'slug' }

Christopher Lenz also brought this up.  My inclination is something like:

environ['wsgi.url_vars'] = {'__args__': ('2006', '06', '12', 'slug')}

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?

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