Exercise 2: Identifying the Positional Mix-Up Precisely — Possible Solution
====================================================================

THE CONSTRUCTOR'S PARAMETER ORDER
------------------------------
This chapter's own Computer.__init__ signature is:
    (self, cpu, ram, storage, gpu=None, has_wifi=True,
     has_bluetooth=True, case_color='black')

Ignoring self, the positional parameter order is: cpu, ram, storage,
gpu, has_wifi, has_bluetooth, case_color.

MAPPING EACH ARGUMENT IN Computer('i7', '16GB', '512GB SSD', 'white')
------------------------------
    Position 1: 'i7'          -> binds to cpu
    Position 2: '16GB'        -> binds to ram
    Position 3: '512GB SSD'   -> binds to storage
    Position 4: 'white'       -> binds to gpu (NOT case_color)

Since only 4 positional arguments were given, the remaining
parameters (has_wifi, has_bluetooth, case_color) all fall back to
their default values: has_wifi=True, has_bluetooth=True,
case_color='black' - explaining exactly why case_color ended up as
'black' instead of the intended 'white'.

WHY NO ERROR IS RAISED
------------------------------
Python's own function-calling mechanism doesn't know or care what a
string like 'white' is semantically "supposed" to mean - it only
tracks positions and types. Since gpu accepts any value (there's no
type restriction or validation shown in this chapter's own
constructor), a string like 'white' is a perfectly valid, type-correct
value to assign to gpu, even though it doesn't make sense as an actual
GPU model name. The constructor has no way to detect that the caller's
INTENT (setting case_color) doesn't match where the value actually
landed (gpu) - from the language's own perspective, the call is
completely valid.

WHY THIS IS SPECIFICALLY DANGEROUS
------------------------------
This is precisely why this kind of bug is so easy to miss: the
program runs successfully, produces a real Computer object, and gives
no indication anything went wrong - the only way to catch it is to
inspect the resulting object's own field values afterward, exactly as
this chapter's own verification did, or to avoid the ambiguity
entirely by using named, chained builder methods instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
The answer maps every positional argument to its actual parameter
name precisely, using the constructor's own declared order rather than
guessing, and explains at the mechanical level (Python's own
position-based argument binding, with no semantic validation) exactly
why the mistake produces no error despite being wrong.