[storm] fixing compile_python

[James Henstridge]

As documented in https://bugs.launchpad.net/storm/+bug/349482, I've
run into a few problems with compile_python.

The underlying cause is that some objects in my expression tree either:
 1. don't have a repr() that is a valid Python expression (e.g. <foo
at 0xwhatever>).
 2. have a repr() that is a valid Python expression, but cause an
error when executed with storm.expr as the globals (e.g. uuid objects
would require that the name UUID be in globals).

Both cases cause problems because the code in storm/store.py is only
catching CompileError exceptions when using
compile_python.get_matcher().

Given that the overall aim of compile_python is not to generate a
string representation of an expression but rather to create a matcher
function, trying to convert constants to Python expressions seems
unnecessary.  All we really need is a way to make those constants
available to the matcher function.

Attached is a proposed change to implement this change.  It should be
work fine for the purposes of get_matcher(), but might be a problem
for other uses (e.g. if someone is using it for debugging?).  At the
moment, the only real breakage I've seen was in tests that were
expecting to see the string representations of the constants in the
output ...

Does this look like the right way to go to solve this problem?  If so,
we could probably also simplify the handling of Column objects, and
pass the actual Column instance to the get_column() function rather
than a string.  That'd remove the need for building up the name ->
column dictionary in ResultSet.cached().

James.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile-python-changes.patch
Type: text/x-diff
Size: 1348 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/storm/attachments/20090423/98e4bf62/attachment.bin