Exercise 3: The score > 90 & score < 100 Precedence Bug — Possible Solution
====================================================================

GIVEN
------------------------------
if score > 90 & score < 100:   (using bitwise & instead of and)
score = 95

STEP 1: HOW THIS ACTUALLY PARSES
------------------------------
Per this chapter's own precedence rule, & binds tighter than
comparison operators, so this is actually parsed as a chained
comparison:

score > (90 & score) < 100

STEP 2: EVALUATE FOR score=95
------------------------------
90 & 95 (bitwise AND): 90 = 1011010, 95 = 1011111 in binary.
90 & 95 = 1011010 = 90.

So the expression becomes: 95 > 90 < 100
This is a chained comparison: (95 > 90) and (90 < 100)
= True and True = True

RESULT FOR score=95: True — happens to match what the programmer
actually intended (95 genuinely is between 90 and 100), but only
by coincidence: the bitwise AND of 90 and 95 happened to still land
in a range that produces the "right" chained comparison result,
not because the expression is actually doing a range check.

STEP 3: FIND A SCORE WHERE IT BREAKS
------------------------------
Try score = 150 (clearly NOT between 90 and 100):

90 & 150 (bitwise AND): 90 = 01011010, 150 = 10010110 in binary.
90 & 150 = 00010010 = 18.

Expression becomes: 150 > 18 < 100
Chained comparison: (150 > 18) and (18 < 100) = True and True
= True

RESULT FOR score=150: the buggy expression says True (score is
"in range"), but the correctly-parenthesized version,
(150 > 90) & (150 < 100), correctly evaluates to False, since 150
is obviously not between 90 and 100. This is a genuine, silent
wrong answer - the exact kind of bug that can slip through testing
if only "obviously in-range" or "obviously out-of-range-in-a-way-
that-still-works" values happen to get tested.

WHY THIS WORKS AS AN ANSWER
------------------------------
The precedence-driven parse is shown explicitly rather than just
asserted, the score=95 case is correctly identified as
"accidentally correct" rather than assumed to prove the code is
fine, and a genuinely different score value is found and verified
to produce a real, silent, incorrect result - directly satisfying
the exercise's own request for a case where the bug actually
matters.