Phillip J. Eby wrote:

At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:

...

I don't see why not to use prefix matching. It is more consistent with the handling of the default application ('', instead of a method that needs to be overridden), and more general, and the algorithm is only barely more complex and not what I'd call sophisticated. The default application handling in particular means that AppMap isn't really useful without subclassing or assigning to .default.

Prefix matching wouldn't show off anything else in wsgiref,

Right, that would be taking away one of the main reasons to include it.

That's putting the cart in front of the horse, using a matching algorithm because that's what shift_path_info does, not because it's the most natural or useful way to do the match. I suggest prefix matching not because it shows how the current functions in wsgiref work, but because it shows a pattern of dispatching WSGI applications on a level that is typically (but for WSGI, unnecessarily) built into the server. The educational value is in the pattern, not in the implementation. If you want to show how the functions in wsgiref work, then that belongs in documentation. Which would be good too, people like examples, and the more examples in the wsgiref docs the better. People are much less likely to see examples in the code itself.

To make the real dispatcher, I'd flesh out what I wrote a little bit, to handle the "default" method in a more meaningful way, including the redirect. All that should only add a few lines, however.

It will still be only a couple lines less than prefix matching. Another issue with your implementation is the use of keyword arguments for the path mappings, even though path mappings have no association with keyword arguments or valid Python identifiers. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

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@colorstudy.com | http://blog.ianbicking.org