lucumr

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 :-)

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 :-)

Wohoo. We finally migrated all of our subversion hosted projects to mercurial. And the best part: we now have a separate trac instance for each of those projects. mod_wsgi does a great job hosting all those tracs without having to add each trac to the config separately. I will post a commented version of our mod_wsgi config in the next days, for the moment still some other things are in the pipeline.

The new developer platform of Jinja, Pygments and all the other projects is on dev.pocoo.org. Note that most tracs are still empty because we haven’t had the time to move the tickets and wiki pages over. For that we have to write a conversion script first.

The plan for the next weeks is releasing Jinja 1.2 and Werkzeug 0.1. The latter is missing some unittests. After that I want to work on pocoo to finally get a working version. TextPress itself is now in the repositories (if you don’t know what it is, just ignore it for now), guess most of use will contribute some code in the next weeks but don’t expect an release. Want to convert this blog here soon though.

Last but not least: hello planet django :)

First of all: Pocoo gets some love recently. EnTeQuAk joined the team and is working on finishing the changes I haven’t finished (conversion to werkzeug and splitting up the packages). That’s great news, but don’t expect checkins the next nine days, he’s on holiday currently.

The other news affects Jinja. The plan was to introduce a new module system for the next Jinja version so that the loaders reload better and that you can use macros without including a module into the current namespace. So {% include foo = “foo.html” %} {{ foo.macro() }} should work.
This however was postponed for a simple reason. The compiler package Jinja is using internally is deprecated because with Python 2.5 the AST is a core Python feature and automatically in sync with the parser Python uses itself. But because maintaining a version for python2.5/2.6, python3 and python2.4 and lower is too much work Jinja will get a hand-written parser for the current syntax.

I expect that this will Jinja also a lot more lightweight because some of the trickeries I do with the AST will become redundant. So that will become the next thing to do.

I now pushed Jinja 1.1 into feature freeze. The trunk is now only used to improve stability, write some more unittests and fix spelling mistakes and stuff like that in the documentation. You can expect a release in about one week.

The changelog so far is huge and the items here are only a very, very short summary with the most important things.

The probably biggest change is the support for {{ super() }}. It works like {{ block.super }} in django, just that it’s a lot more flexible because you can use it like any other function. So you can apply filters on it, put it into a variable, pass it around etc. The whole block system is not a lot more complex in the background, you can render all parents and because of that we also reworked the way Jinja stores debug information. It’s now not a requirement any more to have the sourcecode of the template — the bytecode knows about the debug infos.

We also improved the debugging messages and added support for brace balancing. Now you can set the delimiters of the blocks to ${ and } and still use dict literals in it. You can also have the same delimiters for blocks and variables now, similar to smarty. Other synax improvements: You can now use parentheses for macro definitions: {% macro foo(bar, baz %} instead of {% macro foo bar, baz %} which is a lot easier to read if the editor doesn’t highlight the function name.

Strings without unicode characters are now stored as bytestrings. While this is a bit slower than unicode everywhere it allows to use datetime.strptime and friends which only accept bytestrings. On the other hand an optional C implementation of the context baseclass was added. Variable lookups in the Jinja context are now a lot faster if installed with this module.

A bunch of bugs were also fixed, especially regarding old-style classes and invalid signatures for exceptions. Also the CachedLoader mixing works now for both memory and disk caching which just partially worked in the 1.0 release version.

Last but not least: A new {% call %} tag is available that allows to pass executable template code to a macro. It works exactly like Ruby blocks, just for Jinja templates :-)

If you want to upgrade to the development version to help fixing the latest bugs etc. consider deleting the cache files of your templates first if you have the disk cache enabled.

You can find other changes in the changelog, it’s quite long :-)

Update: here the results from the bigtable benchmark:

Django Templates                              415.52 ms
Jinja Templates                               142.40 ms
Kid Templates                                1202.83 ms
Genshi Templates                              635.37 ms
Cheetah Templates                              56.52 ms
Mako Templates                                 50.09 ms