[Web-SIG] wsgi.url_vars feedback

[Luke Arno]

On 10/23/06, Ian Bicking <ianb at colorstudy.com> wrote:
> 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?

Since numbers are not legal names for named groups
anyway, why not just put them in the dict? It seems
easier in more cases.

Of course, this is more difficult in the case of handling
an unknown number of positional args, but that case
seems rather far off into the corner, no?

(By the by, I consider named groups a best practice as
there is a tighter dependency between code and URI
with positional args. Sometimes it may not matter but...)

Cheers,
- Luke