Werkzeug 0.1 Released
Finally (sorry for the long delay) Werkzeug 0.1 is out. Here parts of the current featurelist:
- Provides Request and Response objects for WSGI
- Handles file uploads by using temporary files for incoming data.
- Provides a middleware for static data for development purposes
- Tiny wrapper around wsgiref for easier development (autoreload, optional
multithreaded enviornment) - Unicode aware data processing. Just use unicode everywhere, werkzeug
handles that for you. - Mini template engine. Sometimes string formattings just are not enough
and real template engines are too big for that tiny task. - Context locals. Don’t pass request/user/database connections and
other objects around. Put them on a global context local object and
werkzeug makes sure that everyting is cleaned up end delivered well. - Test utilities. Create fake WSGI environments and requests to test
your application. - Interactive debugger. Application dies with an error? Hook the debugger
in and inspect every frame.
Here a screenshot of the debugger in action:
Small werkzeug example applications can be found in the trac. In the werkzeug.contrib package are also some pieces of code that can be useful for django developers. For example there is a stream wrapper that limits incoming form data to a given number of bytes. This is useful for django because django streams into the memory and not to the file system.
Have fun and report bugs / feature wishes in the trac :-) Get it while it’s hot from the Cheeseshop.
Congratulations!
This is a really nice lib, thanks for it.
I’m using it with pleasure.
Comment by Rafael — Sunday, December 9th, 2007 @ 7:03 pmWe really could use this web-based console debugger as an option on Django’s debug pages. How difficult was it for you to implement?
Comment by Eric Florenzano — Sunday, December 9th, 2007 @ 11:12 pmThere are ways to get that debugger running in django but it’s not that easy because django keeps on catching exceptions in the core. That means they are never forwarded to the WSGI layer where the werkzeug debugger operates.
If one adds a way to disable the internal debug view and hook in WSGI middlewares, adding werkzeug.debug should be a simple task.
Regards,
Comment by Armin Ronacher — Monday, December 10th, 2007 @ 7:31 amArmin
Your debugger is very nice. It even looks nicier that Paste’s one. Do you have plans on releasing it as a separate package so every WSGI applications developers could use it? It would be great to have such a package. For example, we currently use Paste’s evalexception debugger in our Zope3 development, but werkzeug’s one looks so great, I’m going to try it with Zope3… :)
Comment by Dan — Monday, December 10th, 2007 @ 7:53 amI already did that. That package is called werkzeug ;-) Seriously. Werkzeug plays very well with other packages and it’s a very small package, about 3000 lines in total. So no real need to further unbundle the debugger.
Regards,
Comment by Armin Ronacher — Monday, December 10th, 2007 @ 8:11 amArmin
Excellent work! I have been using Werkzeug for a good while now, and I can strongly recommend it to any web developer.
Comment by Ali Afshar — Monday, December 10th, 2007 @ 1:57 pmWerkzeug always leaves me a little… baffled. The feature list is so closely matched to Paste and its related libraries.
For instance:
request/response: paste.wsgiwrappers, and now webob
file uploads: well, the cgi module automatically does that
static files: paste.fileapp and paste.urlparser.StaticURLParser
wsgiref wrapper: paste.httpserver and paster serve
unicode: paste.wsgiwrappers/webob
mini template engine: tempita
context locals: paste.registry
test utilities: paste.fixture.TestApp and now webtest
interactive debugger: paste.evalexception and now weberror
I don’t particularly mind this duplication, but I’m confused by it. Why reimplement everything? (And you aren’t even the only one, Luke Arno’s libraries have the same pattern of reimplementation.)
Comment by Ian Bicking — Monday, December 10th, 2007 @ 6:39 pmIan: Well. Unfortunately some project evolved next to each other. Colubrid started long ago and some parts of it are either bad implemented and/or silly. However it was still one of the smallest libraries so I thought about uncoupling the request and response objects, the debugger and some other functions there. I also wanted a slightly improved version of string.Template so that was that template engine thing.
However I missed for some time that you started a very similar thing namely webob and tempita. I guess if those projects would have existed for a little longer some parts of werkzeug would probably not exist as such.
One of the reasons why I never really felt that happy with paste was that it brings a lot of stuff I personally don’t want to use and lacks things I need every day. There are exceptions for every status code, how many of those do you actually use? There are request objects but the file handling feels a lot like the cgi module thanks to the FieldStorage. Long time ago I had big problems with unicode because paste was lacking unicode support everywhere. Paste comes with interesting stuff but most of them I don’t use (like paste deploy, SCGI, paste config, transactions) which make 20.000 lines of code and lack things I would actually use (like URL routing, the Werkzeug debugger [yes, there is evalexception, however my sense for aesthetics and usability prefers the Werkzeug one, sorry for that], a simple way to generate custom management scripts without installing PasteScript).
At the end of the day Werkzeug is a very small library bundling everything you need to bootstrap your own WSGI application in no time and I’m very happy with the feature/lines of code ratio. And even if I was the only person using Werkzeug the work of the last half year was worth the effort. And unlike Colubrid it’s predecessor you can mix it with any other library out there which makes it a good addition to existing libraries.
Hope I could defend my POV :-)
Regards,
Comment by Armin Ronacher — Monday, December 10th, 2007 @ 7:10 pmArmin
FWIW, I personally feel that choice is good. I do not buy in to this argument that in Python there should always be only one way of doing things. If one were to pursue that ideal to the end then you will just end up with a monopolistic mono culture that would more than likely stagnate.
When different parties do implement similar things they are never really the same anyway, as each will incorporate different ideas as to how to go about solving the problem. This is important and any decent programmer would look at what other people are doing in the Python community and learn from others successes, as well as their failures. It is only through this cross fertilisation of ideas and learning from others that as a whole the quality and utility of code will move forward.
The other thing with competing solutions is that they usually have different trade offs, and as such, which one is better for a particular scenario will depend on the sort of application or environment it is used in. No one solution will always be the best at everything.
As such I feel that trying to suppress people from doing their own thing and trying to make them use a specific package is in the end run counter productive. If a solution is not good it will die its own death. If it is a good solution and for good reason, it could well become so successful as to replace all other existing solutions, even if only for a time.
So, empires will come and go, this will never change and we shouldn’t try and stop it.
Comment by Graham Dumpleton — Tuesday, December 11th, 2007 @ 2:19 amThank you for releasing this, have looking for something lightweight like this for a while.
Comment by Adam Hinds — Wednesday, December 19th, 2007 @ 10:00 am[…] Ronacher has released Werkzeug 0.1 a little while ago. As the website for Werkzeug says: “Werkzeug is a collection of various utilities for WSGI […]
Comment by In Nomine - The Lotus Land » Werkzeug 0.1 released - WSGI toolbox — Friday, December 21st, 2007 @ 11:48 amWerkzeug is a gem, to the point, elegant, lean code. Luke Arno’s libraries have a similar quality, the conventions are natural, the code is easy to follow, build upon and adapt to. Unlike Paste, where I first got turned off by StackedObjectProxy, after realizing it was just a glorious wrapper for threading.local. And while this generic header parser-composer is, well generic, I can deal with raw header strings just fine, hence I use Werkzeug. Thanks for sharing it.
Comment by propanbutan — Sunday, December 23rd, 2007 @ 4:04 pmPS. Is pocoo dead or just hibernating?
Wow, very impressive. I plan to dig through this code just for the learning value if nothing else. I too would like to see this type of web-based console debugger available in Django. Thanks again for your contribution.
Comment by Empty — Monday, December 24th, 2007 @ 5:59 pm