Lingua 3.6: improved template handling and a new extraction API

Lingua is a Python package that helps you find translatable texts in
your code, and generate POT-file for them. Think of it as xgettext on
steroids for Python.

Since the last time I wrote about
Lingua a lot has happened. Most
significantly support for message contxts has been added, which can be used
today in Pyramid applications, more information is provided for translators,
and a new API for creating extraction plugins has been added.

Lingua 2.4 released

This is a bugfix release which fixes several problems reported by users.

Lingua is a Python package that helps you find translateable texts in
your code, and generate POT-file for them. Think of it as xgettext on
steroids for Python.

Get your REST on

TL;DR: rest_toolkit is a new
framework to create REST applications, build using Pyramid.

For two recent projects involved implementing a REST service. The experience
of doing that led me to create a new simple but extendible toolkit for buidling
REST applications. Want to see how simple? This is a full REST application:

@resource('/')
class Greeting(object):
    def __init__(self, request):
        pass

@Greeting.GET()
def show_root(root, request):
    return {'message': 'Hello, world'}

quick_serve()

Lingua 2 released

This new release was planned for a long time: initial plans were made
a long time ago, and development was started it at the Pyramid NOLA sprint
last February. Since I just finished a project and am looking for new work I
had some time to finally finish Lingua 2.

Lingua is a Python package that helps you find translateable texts in
your code, and generate POT-file for them. This version incudes
significant improvements in processing Python and HTML files. This
release also shifts Lingua from working as a Babel extraction plugin
to being a standalone tool. This made it possible to work around
several limitations and bugs the Babel framework enforced.

Task queues

When writing a web application or REST backend I occasionally run into a
common problem: sometimes I need to do things that will take a while: sending a
push notification to mobile apps, generating emails or doing an expensive
calculation. Doing this immediately would result in very long response times,
which is not acceptable. That means I need a way to offload those to something

Allowing unicode ids in Zope

Back when Zope was written Python did not support unicode. This is still reflected in the policy for object ids in Zope: they must be pure ASCII. I recently started wondering what it would bring Zope a bit closer to the future and make it support UTF-8 ids. It turns out that this is doable without too much effort.

Developing for the browser

In a recent blog post Andy Mckay asked if javascript apps are ready for business. Having recently spent a fair amount of writing JavaScript I think I can answer that question. Unfortunately the answer at this point in time is a resounding no.

Sqlalchemy In Reverse

When using data in a relational database you often use an Object Relational
Mapper (ORM) so you can pretend that you are only dealing with standard
objects instead of having to deal with SQL directly. The ORM will then
generate SQL automatically for you, and magically turn query results into
objects again. For a recent project I had to do the exact reverse: turn
a SQL expression into a SQLAlchemy construct.

Doing this required building a parser for SQL expressions to generate
a syntax tree, and then converting the syntax tree into a SQLAlchemy
expression.

Migration Frameworks

There is a growing number of migration toolkits for Python: Alembic, sqlalchemy-migrate, GenericSetup, zope.generations, south, etc. All of these focus on migrating a specific type of database, and some even on migration within a specific type of application (Zope or Django). They work very well, but when you need to deal with larger applications they no longer suffice.