Exercise 2: WHERE name != 'Alice' — A Genuinely Different Query, Not Just an Inverted Answer — Possible Solution
====================================================================

THE TEST
------------------------------
    db.execute("SELECT * FROM users WHERE name != 'Alice';")
    # table has: [1,'Alice',30], [2,'Bob',17], [3,'Carol',45]

RESULT
------------------------------
    [[2, 'Bob', 17], [3, 'Carol', 45]]

Exactly the two rows whose own name is NOT 'Alice'.

WHY THIS IS THE CORRECT RESULT
------------------------------
_execute_select's own filter runs OPS['!='](row_value, where_value)
for each scanned row, where OPS['!='] = lambda a, b: a != b. For
Alice's own row, row_value is 'Alice', so 'Alice' != 'Alice' evaluates
to False -- `if not False: continue` never triggers a skip... wait,
tracing precisely: `if not self.where_applier(...): continue` means
the row is SKIPPED when where_applier returns False. For Alice's row,
where_applier (via OPS['!=']) returns False (since 'Alice' != 'Alice'
is False), so `not False` is True, and `continue` DOES fire -- Alice's
own row is correctly skipped. For Bob's and Carol's rows,
where_applier returns True (their names genuinely aren't 'Alice'), so
`not True` is False, continue does NOT fire, and both rows are
correctly yielded.

WHY THIS IS A GENUINELY DIFFERENT QUERY FROM "INVERT WHERE = 'Alice'"
------------------------------
It's tempting to think of '!=' as simply "take whatever '=' would
return, and flip it" -- and for THIS specific case, with only three
rows and one clean match, the observable result would indeed look the
same as manually complementing the '=' result against the full row
set. But that equivalence is a coincidence of this particular
comparison being well-defined and total (every row's own name either
does or doesn't equal 'Alice', with no ambiguous or undefined case).
The actual EXECUTION isn't "compute WHERE name = 'Alice', then invert
the result set" -- it's a completely separate, independent pass over
every row, applying '!=' AS ITS OWN COMPARISON, via its own dedicated
entry in the OPS dispatch table. There's no code path anywhere that
computes an '=' result first and then negates it; '!=' is evaluated
directly and standalone, exactly the same way '>', '<', '>=', and
'<=' are each their own independent lambda in OPS, not derived from
one another.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinction matters for correctness in the general case: for
comparisons involving values that might be missing, undefined, or use
custom equality semantics (not a concern for this simplified engine's
own plain Python int/str comparisons, but a real concern in full SQL,
where NULL comparisons famously don't obey simple boolean inversion),
treating '!=' as "the opposite of '='" computed after the fact would
be a fragile shortcut rather than a genuinely correct, independent
operator implementation.