Make the common case simple, let the exceptional case be exceptional.
• Trust Python's exception system• Write code that works as both script and library• Explicit is better than implicit• Errors should never pass silently unless explicitly silenced• Fail fast in one-shot scripts, continue gracefully in long-running services• Use stdlib over regex when stdlib provides the functionality• Check existing project code for API usage before guessing method names
Prefer APIs that fail loudly over ones that silently do nothing. When a library provides both a checked and an unchecked removal/access, use the checked form: verify the precondition first (e.g. Index() before RemoveAt(), find() before erase()), so that a violated assumption aborts immediately at the call site rather than producing silent corruption downstream. Write your own assert or early-return guard for every assumption that “should never happen” — if it ever does, you want to know exactly where.
Richard Gabriel identified two opposing design philosophies: “The Right Thing” (the MIT approach) and “Worse is Better” (the New Jersey approach). The Right Thing demands that correctness is non-negotiable, interface simplicity outweighs implementation simplicity, consistency is as important as correctness, and completeness is never casually discarded. Worse is Better inverts these priorities: implementation simplicity comes first, correctness can be compromised for it, and completeness is the first casualty. Gabriel himself conceded that Worse is Better has better survival characteristics — it spreads faster, accretes a user base, becomes entrenched — but that is a sociological observation about software adoption, not a prescription for how to write code. We reject it as a design philosophy. We aim for The Right Thing: correct in all observable aspects, consistent, complete in the cases that matter, and with interfaces that are simple for the caller even when the implementation must bear the cost. There is one specific carve-out: swallowing exceptions silently is not simplicity, it is negligence. An unhandled exception is always worse — unless it is genuinely, deliberately handled, in which case the failure mode and all relevant context must be thoroughly logged at the point of catch so that the suppression is auditable and diagnosable. Silence is never acceptable; either propagate the error or document its burial.