8.14 Best Practices

Choose the Right Data Type

Convert to the type that actually matches how the value will be used — don’t leave a numeric value as str just because that’s how it arrived.

Avoid Unnecessary Conversions

Convert once, as early as possible after receiving external data, and work with the properly-typed value from then on — repeatedly converting the same value back and forth wastes effort and invites bugs. See 8.11 Memory and Performance.

Validate User Input

Never assume input() or an external field will parse cleanly — wrap conversions of untrusted data in try/except (see 8.10 Safe Type Conversion) as standard practice, not an afterthought.

Quick Interview Answer

“Three habits cover most of what matters: convert to the type that actually matches how a value will be used, rather than leaving everything as str; convert once, as early as possible after receiving external data, instead of repeatedly re-converting the same value; and treat validating untrusted input — user input, env vars, API fields — as a default, not something bolted on after a bug report.”

Common Mistakes

• Leaving a value as str throughout a codebase “because it arrived that way,” pushing the conversion responsibility onto every caller instead of doing it once at the boundary.
• Adding input validation only after a production incident, instead of treating it as the default for any data crossing a trust boundary.