lucumr

Wohoo. Werkzeug 0.2 is out now. 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.

So, what’s new in 0.2? Countless things and too many for this small list, but here the most important ones:

• The path converter limitation is gone. rejoice!
• In the contrib package there is now a secure cookie (basically a hashed a client side session storage)
• Exceptions can now return response objects so that you can add headers etc.
• You can now convert a response object to a different type of response objects on the fly (for example if you have your own response object subclass with special features but the response object returned by a function is a simple BaseResponse)
• There are a bunch of extra features for response and request objects now (available as mixin classes) for HTTP header parsing and dumping
• All the routing exceptions are now HTTPExceptions which simplifies dispatching a lot
• werkzeug.script has a much simpler way of specifying boolean parameters
• lazy_property is now called cached_property, update your code!
• many cool small helper functions that deal with python modules and packages. There is find_modules which can return a generator for all the modules below a package and import_string which allows you to simply import objects from a string. No more __import__ hackery needed.
• the usage of the map adapter is much easier now too and a lot more rest compliant. See the new documentation
• dozens of small fixes and additions!

There is also a new website and documentation and the tutorial was translated to German. For 0.3 we hopefully have some more translations for the tutorial and a better documentation for the contrib modules which are currently just documented in docstrings.

Grab it from the cheeseshop while it’s hot.

The last four days I attended our first offline-webteam meeting and it was fun ;-) We spend a few days hacking on various parts of the ubuntuusers software and had a great time. While it’s pointless to talk about what we did because hacking on broken code is not that much fun as such (unless you can laugh about PHP bugs and stuff like that) I think we can present some of the changes with the upcoming hardy release.

Don’t expect too much but that shows that we are doing something even if you think development on the German portal software is stalled. That’s certainly not the case.

But we are once again looking for web designers. The sourcecode is multilingual and the development takes place in both German and English for potential future translations to other languages than German, so you can participate even if you are not speaking German :-) If you are interested in participating and if you have advanced XHTML1/HTML4/CSS2 skills, we want you for ubuntuusers webteam!

If you are interested mail me at mitsuhiko you know what comes next ubuntu dot com.

Currently on pocoo.org is a semi static webpage with a completely unmaintained semi static blog and completely outdated information. While pocoo is not dead yet (just resting) it’s time to put something on the front page that represents the current state of the situation in a better way.

Let’s see if we can get that updated in the next two weeks. Oh, and TextPress is now up to date again, a bunch of bugs were fixed and we’re much nearer to a release than some weeks ago, but unfortunately we’re behind the roadmap once again :-)

I now installed the Werkzeug example applications on pocoo.org. So you don’t have to pull all the code if you want to try them out :-)

Here is the Wiki and the Planet. Have fun testing.

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.

Finally Jinja 1.2 is released. It took a long time because this release introduces basically a complete rewrite of the parser and parts of the lexer. With Jinja 1.2 onwards the template engine has its own parser which makes it possible to introduce new syntactical elements and change operator precedence (especially regarding the filter operator which finally binds harder than plus). We added more unittests to check if Jinja stays compatible with the python semantics we had previously and all 153 tests pass :-)

With the new parser we also simplified the syntax a bit, made the “call” a keyword now and added a couple of new features. For example the debugger (with the optional c extension compiled) is now able to rewrite all jinja frames in a traceback so you will never find yourself in the situation where line numbers don’t match the template line numbers.

Another new syntax feature are conditional expressions derived from python2.5 ({{ foo if expr else bar }}). foo.0 is now the same as foo[0] for compatibility with django and tuples are finally tuples and not lists which makes it possible to use string formattings with more than one value. Test functions with one parameter don’t need parentheses so {{ foo is feeling(well) }} can now be written as {{ foo is feeling well }}.

We also added a concatenation operator that converts all arguments into a string automatically to concatenate them. This is very useful if you have some integers and other values you want to join: {{ foo ~ bar ~ baz }}, which is equivalent to {{ foo|string + bar|string + baz|string }}.

Another great new feature (if you are a django user) is the new django support module which makes it a lot easier to integrate Jinja into django. It makes it possible to use django filters in Jinja and load from the same folders.

Aside from that there are couple of improvements and bugfixes. As always you can easy install Jinja directly from pypi or download it.

If you have a look at the current pocoo homepage or the trac you will find out that the project is more or less unmaintained right now. There are many reasons for that but the most important one is that we will probably rework some parts of the webpage in the next time. Why is it like that? About two years ago I was working together with some other people (some of them are now part of the pocoo team) on the German ubuntu portal ubuntuusers.de. We have used and still use a heavily modified phpBB, MoinMoin wiki engine and some other components implemented as django pre-magic removal. Back then WSGI was something that just was a PEP and no implementation.

My big plan was to create a replacement for phpBB in Python and integrate it with Moin. However, two years later it looks like that this is not the best solution either. The main problem with have on ubuntuusers is not, that we have different programming languages, we have different auth systems, templates, databases, storage systems etc. One minor change in a template requires modifications in three different applications.

While we don’t have a solution for ubuntuusers *yet* it turns out that pocoo won’t be one either. However pocoo was and is no failure. One the long path to pocoo we created some good and not so good libraries. There was Colubrid which was one of the first WSGI dispatchers out there and it’s successor Werkzeug which will have it’s first release in two weeks. There is Jinja which is now used on a couple of big django projects, there is Pygments which soon became the favorite sourcecode highlighter of many developers, there will be TextPress around this Christmas, which will be the first big python blog engine as far as I know. Georg Brandl also started the new python documentation project in the pocoo repositories where some of us contributed some code or knowledege.

But what will happen to pocoo? Right now nothing, just that we will probably replace the pocoo.org index page with something that points directly to the projects. After christmas (in fact after the TextPress release) I want to have another look at the pocoo sourcecode and make parts of the code standalone packages. For example the config file parser. And after all that half of the team will have finished a different project which currently takes some of our time and continue working on the pocoo forum, probably with a different name and finally based on all the libraries that evolved around it.

Why I’m writing that today? Around that date two years ago I was setting up the pocoo.org server and reading the WSGI specs. From then on two years of hacking on multiple pieces of software where some of them became popular enough that people are using them :-)

So in that sense: Thanks Georg, Alexander, Benjamin, Christopher, Lukas, Ferdinand, Tassilo and all the others that worked on the pocoo projects :-)

From yesterday 18:00 until now pocoo.org and all the related domains (including wiki.python.de and pygments.org) where down because we moved all the xen instances to a new hetzner server. However the RAM usage by the instances is still unchanged so there will be another small downtime in the next few days. And small is ~20 minutes. Because I expected that the migration will take less time I have to postpone the upcoming Jinja release until Saturday.

Additionally we’re struggling with a mod_wsgi bug that is probably not mod_wsgi’s fault. Under certain conditions a C extension seems to not release the GIL which the result that one apache process consumes all the processor power available.

Sorry for the inconveniences caused.

Update: resource relocation done (for the moment at least)

The ubuntuusers team acquired two new webdesigners this week and the first thing that they missed was a var_dump replacement. In fact that thing is really missing. Python does have a pprint library but it’s not extensible. Impossible to dump normal objects.

I worked today on a port of ruby’s pp library (wanted to call it pp, but that’s already reserved by parallel python). Check it out in the cheeseshop: pretty.

Classes can implement __pretty__ to prettyprint their structure.

I would love to see that as replacement for the builtin pprint library which is impossible to extend. pretty is not yet 100% backwards compatible, some reprs look different, but that’s extensible. Check out the module docstring for some examples.

The new version of Pygments is out now. The changelog is once again quite long and a couple of new lexers were added:

• Erlang
• ActionScript
• Literate Haskell
• Common Lisp
• Various assembly languages
• Gettext catalogs
• Squid configuration
• Debian control files
• MySQL-style SQL
• MOOCode

Some old lexers got updates too:

• Greatly improved the Haskell and OCaml lexers.
• Improved the Bash lexer’s handling of nested constructs.
• The C# and Java lexers exhibited abysmal performance with some input code; this should now be fixed.
• The IRC logs lexer is now able to colorize weechat logs too.
• The Lua lexer now recognizes multi-line comments.
• Fixed bugs in the D and MiniD lexer.

There are also two new formatters. One that outputs SVG documents and a terminal formatter that uses 256 different colors if the terminals support that. There is also a new style which resembles the vim7 default style.

For the full list of changes have a look at the changelog. You can download pygments from the download page. Happy coloring!