>> If this normalized version would be used in a "refine search" input
>> field of the result page -- or displayed/inserted by some AJAX
>> functionality -- it could make the whole feature quite
>> self-explanatory.

> I don't understand the purpose of the expression function.

Probably you misunderstood the idea of the *normalized* version (which
is not the same as the Python expression).  This 'normalized' method is
not active in my submitted module because of an obscure "SyntaxError"
(nothing obvious at the stated position, but the error is there on my
system in Python 2.3 ... 2.6, and it is not related to the .pyc file). 
It's purpose is to provide the best and most expressive version of the
input expression to support users and prevent them from thinking they
have executed a search which they in reality haven't.

As mentioned before, the purpose of the expression function is:
development, prove of concept, testablity;  a small step before the SQL
expression.  Furthermore, I'm not sure whether all of our database
backends support expressions like "a BETWEEN x AND y" or "a IN (1, 2,
5)", and IIRC we store integers as CHARs;  reasons enough to use Python
expressions for a first shot, I think.