Question about ast.literal_eval

[Frank Millman]

On 21/05/2013 09:21, Steven D'Aprano wrote:
> On Tue, 21 May 2013 08:30:03 +0200, Frank Millman wrote:
>
>> I am not sure I can wrap my mind around mixed 'and's, 'or's, and
>> brackets.
>
> Parsers are a solved problem in computer science, he says as if he had a
> clue what he was talking about *wink*
>
> Here's a sketch of a solution... suppose you have a sequence of records,
> looking like this:
>
> (bool_op, column_name, comparison_op, literal)
>
> with appropriate validation on each field. The very first record has
> bool_op set to "or". Then, you do something like this:
>
> import operator
> OPERATORS = {
>      '=': operator.eq,
>      'is': operator.is_,
>      '<': operator.lt,
>      # etc.
>      }
>
> def eval_op(column_name, op, literal):
>      value = lookup(column_name)  # whatever...
>      return OPERATORS[op](value, literal)
>
> result = False
>
> for (bool_op, column_name, comparison_op, literal) in sequence:
>      flag = eval_op(column_name, comparison_op, literal)
>      if bool_op == 'and':
>          result = result and flag
>      else:
>          assert bool_op == 'or'
>          result = result or flag
>      # Lazy processing?
>      if result:
>          break
>
> and in theory it should all Just Work.

That's very clever - thanks, Steven.

It doesn't address the issue of brackets. I imagine that the answer is 
something like -

   maintain a stack of results
   for each left bracket, push a level
   for each right bracket, pop the result

or something ...

I am sure that with enough trial and error I can get it working, but I 
might cheat for now and use the trick I mentioned earlier of calling 
eval() on a sequence of manually derived True/False values. I really 
can't see anything going wrong with that.

BTW, thanks to ChrisA for the following tip -

import operator
ops = {
   'in':lambda x,y: x in y,  # operator.contains has the args backwards

I would have battled with that one.

Frank