Werkzeug started as simple collection of various utilities for WSGI applications and has become one of the most advanced WSGI utility modules. It includes a powerful debugger, full featured request and response objects, HTTP utilities to handle entity tags, cache control headers, HTTP dates, cookie handling, file uploads, a powerful URL routing system and a bunch of community contributed addon modules.Having coded applications in Aquarium, Django, Pylons, Ruby on Rails, Zope, Plone, etc., I've been fascinated by the idea of an anti-framework. A framework establishes the flow of the application and calls your code at certain points. That's the opposite of a library. A library lets you call its code whenever and however you want. Werkzeug is a collection of libraries.
Werkzeug is unicode aware and doesn't enforce a specific template engine, database adapter or anything else. It doesn't even enforce a specific way of handling requests and leaves all that up to the developer.
Werkzeug is most useful for end user applications which should work on as many server environments as possible (such as blogs, wikis, bulletin boards, etc.).
There's a bunch of glue that's required to tie all the libraries together in order to build a Web application. Werkzeug gives you some code as an example, but basically, you're on your own. Hence, it's not for everyone, but it's great if you're someone like me who hates when things get in his way.
Anyway, it looks simple and clean. The tutorial was very good. Here are some other random comments:
The tutorial used Jinja which is a templating system based on Django templates. Personally, I don't like Django templates. (That's not an insult. Templating engines are a matter of taste.) Fortunately, there's absolutely nothing in Werkzeug tying you to any templating system or ORM. It doesn't even make it any easier to stick to Jinja.
Werkzeug has view functions like Django instead of controller classes with methods like Pylons. I personally prefer the Pylons approach since I can do a lot of stuff before and after the method call. On the other hand, I guess that just means I'd have to make better use of decorators. It's interesting because the tutorial itself said "A callable class has huge advantages over a function" when it was talking about the WSGI entry point. Of course, you're free to not use the built in URL dispatcher, in which case you could do whatever you want ;)
Like Pylons, parameters parsed from the URL path are passed in as arguments to the functions. Unlike Turbo Gears, form parameters are not passed in as function arguments. I don't personally like that approach anyway.
I love the way it's just a bunch of libraries and you have to write all the glue code. They show you examples for all the glue code. I can definitely see where I'd be less likely to get irritated by frustrating restrictions.
It supports the Pylons goal of having multiple instances of the same application in the same Python interpreter.
Rather than putting all your URL mappings in one place, they also show you how to declare your mappings on a per-view basis using function decorators.
They made it easy to write management scripts that operate outside a Web context, yet understand how to work with the app.
In the tutorial, they hard coded the dburi in the top-level module manage.py. Especially in the past, I use to get frustrated while using Pylons because I would need the dburi and it would be locked away in a .ini file. In order to support multiple instances of the same application in the same process, you need a procedure to get access to the correct .ini file, and in strange situations like management scripts, etc., it was hard to get access to this stuff. In Werkzeug, you're on your own to figure out how you want to manage your configuration data. That's fine with me--I've always disliked .ini files anyway ;)
It looks like you return redirects as instances. In a lot of systems like Pylons and Aquarium, when you do a redirect, it actually raises an exception to halt processing.
It does look like it's easy to create a hierarchy of views in a hierarchy of Python modules. That's good.
Well, I haven't written an application with it, but it looks nice ;)