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