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 | [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