[Python-Dev] [Web-SIG] Adding wsgiref to stdlib

Sat Apr 29 02:48:42 CEST 2006

Phillip J. Eby wrote:
> At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>> It will still be only a couple lines less than prefix matching.
>> That's beside the point. Prefix matching is inherently a more complex 
> concept, and more likely to be confusing, without introducing much in 
> the way of new features. 

I just don't understand this. It's not more complex. Prefix matching 
works like:
 get the prefixes
 order them longest first
 check each one against PATH_INFO
 use the matched app
 or call the not found handler
Name matching works like:
 get the mapping
 get the next chunk
 get the app associated with that chunk
 use that app
 or call the not found handler
One is not more complex than the other.
> If I want to dispatch /foo/bar, why not just use:
>> AppMap(foo=AppMap(bar=whatever))

You create an intermediate application with no particular purpose. You 
get two default handlers, two not found handlers, and you create an 
object tree that is distracting because it is artificial. Paths are 
strings, not trees or objects. When you confuse strings for objects you 
are moving into framework territory.
> If I was going to include a more sophisticated dispatcher, I'd add an 
> ordered regular expression dispatcher, since that would support use 
> cases that the simple or prefix dispatchers would not, but it would also 
> support the prefix cases without nesting.

That is significantly more complex, because SCRIPT_NAME/PATH_INFO cannot 
be used to express what the regular expression matched. It also 
overlaps with frameworks. WSGI doesn't offer any standard mechanism to 
do that sort of thing. It could (e.g., a wsgi.path_vars key), but it 
doesn't. Or you do something that looks like mod_rewrite, but no one 
wants that.
Prefix based routing represents a real cusp -- more than that, and you 
have to invent conventions not already present in the WSGI spec, and you 
overlap with frameworks. Less than that... well, you can't do a whole 
lot less than that.
-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org