Common pitfalls and best practices

When a function parameter has a mutable default like an empty list, the same object is shared across all calls. Modifications persist between calls, leading to surprising behavior. The standard fix is to use None as the default and create the mutable object inside the function body.

When closures are created in a loop, they capture variable names rather than values. By the time the closures are called, the captured variables hold the final values from the loop. The fix is to capture the value at definition time, often by passing it as a default argument.

Modifying a list during iteration produces unpredictable results because the iterator's internal index gets out of sync with the changing length. The safe approach is to iterate over a copy or to build a new list with the desired elements using a comprehension.

Always use is None or is not None to check for None. Equality with None can be misleading because a custom dunder eq could return true for non-None values. None is a singleton, so identity comparison is the correct and idiomatic check.

Catching all exceptions hides bugs by silently handling unexpected errors. It also catches programming mistakes like name errors and type errors that should crash loudly. Catch only the specific exceptions you can meaningfully handle, and let everything else propagate.

EAFP stands for Easier to Ask Forgiveness than Permission. It is a Python idiom favoring try-except over checking conditions in advance with if. For example, instead of checking if a key exists in a dict and then accessing it, just access it and catch KeyError. EAFP is generally more Pythonic and often faster.

LBYL stands for Look Before You Leap. It means checking preconditions before performing an operation, the opposite of EAFP. LBYL is appropriate when the check is cheap and the operation has expensive side effects. For most cases, EAFP is preferred in Python.

Use a function for stateless operations and pure computations. Use a class when you need to maintain state across multiple operations, when several functions naturally share the same data, or when polymorphism makes the design cleaner. Resist the urge to wrap a single function in a class.

The principle of least surprise says that code should behave the way a reader would expect. Use idiomatic patterns, follow conventions, give variables clear names, and avoid clever tricks that confuse readers. Code is read more often than it is written, so optimize for clarity. ---