compile_python_variable assumes that repr() of variable's value is a valid Python expression
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Storm |
Fix Released
|
Medium
|
James Henstridge |
Bug Description
The compile_python handler for Variable objects is:
@compile_
def compile_
return repr(variable.
This assumes that the repr() of the value inside the variable will be a valid Python expression (and more concretely, a valid expression with storm.expr as the globals).
There are a number of ways this can cause problems:
1. Values that have a repr() like "<something at 0xNNNN>" will give a syntax error, even if there is a compile_python handler for its class.
2. For e.g. UUID objects, while the repr is a valid Python expression, it requires that the name "UUID" be bound:
>>> import uuid
>>> from storm.expr import compile_python
>>> from storm.variables import UUIDVariable
>>> var = UUIDVariable(
>>> matcher = compile_
>>> matcher(None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1, in match
NameError: global name 'UUID' is not defined
>>> import storm.expr
>>> storm.expr.UUID = uuid.UUID
>>> matcher(None)
True
As e.g. ResultSet.set() is only checking for CompileErrors, this causes the method to fail when it would otherwise be able to succeed.
Suggested changes:
1. update compile_
@compile_
def compile_
return compile(
2. define some way for compile_python handlers to inject names into the scope for the matcher function (probably via the state variable).
3. add compile_python handlers for any variable values that don't have them currently.
Related branches
- Gustavo Niemeyer: Approve
- Thomas Herve (community): Approve
- Diff: 303 lines
Changed in storm: | |
importance: | Undecided → Medium |
status: | New → In Progress |
assignee: | nobody → James Henstridge (jamesh) |
Changed in storm: | |
status: | Fix Committed → Fix Released |
tags: | added: tech-debt |
Fix merged to trunk in r307.