On 20/05/2013 18:13, Chris Angelico wrote:
On Mon, May 20, 2013 at 11:26 PM, Frank Millman <fr...@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
--
http://mail.python.org/mailman/listinfo/python-list
