Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Frank Millman <frank@chagford.com>
Subject: Re: Question about ast.literal_eval
Date: Tue, 21 May 2013 10:06:35 +0200
References: <knci07$jol$1@ger.gmane.org> <BLU176-W37EB377C73CD6D7306247DD7AF0@phx.gbl> <knckj0$cft$1@ger.gmane.org> <CAPTjJmpb073XFH5ksNhzRyAJNSJF=6WNq5pGzed4PXqBrJBN=A@mail.gmail.com> <knclk6$lva$1@ger.gmane.org> <mailman.1888.1369056365.3114.python-list@python.org> <519a4b6a$0$29997$c3e8da3$5496439d@news.astraweb.com> <mailman.1905.1369117820.3114.python-list@python.org> <519b2096$0$6574$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
In-Reply-To: <519b2096$0$6574$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1909.1369123609.3114.python-list@python.org>
Lines: 71
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45650

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