8.13 Type Conversion in DevOps

Five places type conversion shows up constantly in real infrastructure scripts.

Environment Variables

os.environ always stores values as str — numeric or boolean-looking env vars must be explicitly converted.

>>> import os
>>> os.environ["MAX_RETRIES"] = "5"
>>> retries = int(os.environ.get("MAX_RETRIES", "3"))
>>> retries, type(retries)
(5, <class 'int'>)

Configuration Files

INI-style config files (via configparser) also return every value as str — the same explicit-conversion discipline applies as with environment variables.

AWS API Responses

boto3 generally returns properly-typed Python values (int, bool, datetime) directly from AWS APIs — but any value extracted from a raw JSON blob in your own code still needs the same JSON-conversion care as 8.12 Type Conversion in File Handling.

Log Parsing

Every field extracted from a raw log line (via regex or split()) starts life as str — durations, status codes, and counts all need explicit conversion before comparison or arithmetic.

status_str = "404"
>>> status_code = int(status_str)
>>> 400 <= status_code < 500
True

HTTP Status Codes

A common real mistake: comparing a status code that’s still a str against an int range, which silently never matches instead of raising an error — always confirm the type before a range/comparison check.

>>> "404" == 404      # different types -- always False, no error!
False

Quick Interview Answer

“In DevOps scripts, type conversion shows up in five recurring places: environment variables (os.environ is always str), config files (configparser is also always str), AWS API responses (boto3 returns properly-typed values, but anything pulled from a raw JSON blob still needs manual conversion), log parsing (every extracted field starts as str), and HTTP status code comparisons specifically — comparing a still-str status code against an int doesn’t raise an error, it just silently and permanently evaluates False, which is a genuinely dangerous failure mode because nothing signals it went wrong.”

Common Mistakes

Comparing os.environ.get("PORT") == 8080 — the env var is a str, so this is always False no matter its actual value, with no exception raised to flag the bug.
Trusting boto3 return types blindly for values that actually originated from a nested raw JSON/string field in the response rather than a native AWS API type.
Not converting a log-parsed duration or count before doing arithmetic on it, producing string concatenation instead of addition.