Fast Web Development with Damsel for Python

Time feels surmountable when looking forward. In retrospect, I see surmise.

My title to this post feels like a real plug piece, but I guess that’s what happens when you’re looking to get indexed. Recently, I tagged two new versions of dmsl in git. If you’ve never heard of dmsl, please go check out the README on github to see what it’s all about.

https://github.com/dskinner/dmsl

I started off implementing haml in python which gave way to a unique direction for the project. I’ve been using it quite actively in work and am continuously enamored with its simplicity and power. Of course I wrote it and there might be a sense of bias, but this isn’t the first or second or third or fourth attempt I’ve made to write something like this. Each of those projects were short lived in the same way that once they were mostly complete, they just flat out didn’t “have it” for me.

0.3-stable is a wrap up of features and fixes over the course of many months of use and has, in the end, proven reliable. This tag is available on github. There were still some annoyances in the code related to speed and the dependency on lxml though that I badly wanted to fix.

The speed issue was solely in the use of a class inheriting python’s Formatter to handle extensions to string substitutions. These substitutions alone could take three times as much of the time as the parser for the whole document. Granted, on a whole, this was still quite a bit faster then a number of template engines out there, but I felt this could be drastically reduced.

The second issue was the dependency on lxml. Simply put, I wanted that to go.

So recently I addressed these issues and tagged 0.4 in git. I’ve also made this tag available on pypi. If installing from pypi, the only dependency is a build environment and python headers for building the C extensions. If building from github, you will need cython 0.15.1+ installed.

0.4 also has another change with how context variables end up in the templates sandbox. Previously, these items were packed in a kwargs dict available to templates. In 0.4, this is no longer the case and those items are unpacked in the environment for use. Planned though is the ability to revert to the old behaviour as needed for upgrading older installs.

While I feel the changes in 0.4 are drastic, unit tests pass and I’ve upgraded my personal projects successfully to do a little stress testing while also using it in another upcoming public project with success.

So check it out and tell me what you think.