Question about ast.literal_eval

[Frank Millman]

On 20/05/2013 18:13, Chris Angelico wrote:
> On Mon, May 20, 2013 at 11:26 PM, Frank Millman <frank at chagford.com> wrote:
>> 0 - for the first entry in the list, the word 'check' (a placeholder - it is
>> discarded at evaluation time), for any subsequent entries the word 'and' or
>> 'or'.
>>
>> 1 - left bracket - either '(' or ''.
>>
>> 5 - right bracket - either ')' or ''.
>
> I think what you have is safe, but extremely complicated to work with.
> Six separate pieces, and things have to be in the right slots... I
> think you've spent too many "complexity points" on the above three
> components, and you're getting too little return for them. What
> happens if the nesting is mucked up? Could get verrry messy to check.
>
> Combining multiple conditions with a mixture of ands and ors is a
> nightmare to try to explain (unless you just point to the Python docs,
> which IMO costs you even more complexity points); the only safe option
> is to parenthesize everything. The system I pushed for at work (which
> was finally approved and implemented a few months ago) is more or less
> this: conditions are grouped together into blocks; for each group, you
> can choose whether it's "all" or "any" (aka and/or), and you choose
> whether the overall result is all-groups or any-group. That still
> costs a few complexity points (and, btw, our *actual* implementation
> is a bit more complicated than that, but I think we could cut it down
> to what I just described here without loss of functionality), but it
> gives the bulk of what people will actually want without the
> complexities of point-and-click code.
>
> The downside of that sort of system is that it requires a two-level
> tree. On the flip side, that's often how people will be thinking about
> their conditions anyway (eg using a pair of conditions ">" and "<" to
> implement a range check - conceptually it's a single check), so that
> won't cost too much.
>

You may be right, Chris, but I don't think my approach is all that bad.

The vast majority of tests will be simple - either a single line, or two 
lines for a range check, with no brackets at all.

If the requirement is more complicated than that, well, I don't think 
the complication can be avoided, and at least this approach gives full 
control.

FWIW, I use the same approach to allow users to construct their own 
WHERE clauses in custom views. Again, the vast majority are simple, but 
there are times when it can get complicated.

The proof of the pudding will be when I try to get ordinary users to get 
their own hands dirty - I am not there yet. If I ever get this released, 
the business model will be free software, but support will be charged 
for. So if a user gets out of his/her depth, there will be assistance 
available.

Time will tell who is right ... ;-)

Frank