How does int(s, base) parse text, and why is base 0 special?

### The signature `int()` has two call shapes: `int(x)` converts a number or parses a string in base 10, and `int(x, base)` parses text in an explicit base. The second argument is **only** meaningful for text: `str`, `bytes` and `bytearray` are accepted, and anything else with an explicit base raises `TypeError: int() can't convert non-string with explicit base`. That is why `int(3.7, 10)` is an error rather than 3 — a float has no digits to interpret in a base. ### Legal bases and their digits `base` must be `0`, or an integer from `2` to `36` inclusive; anything else raises `ValueError: int() base must be >= 2 and <= 36, or 0`. Above base 10 the extra digits are letters, case-insensitively: `a`/`A` is 10 through `z`/`Z` is 35, which is why 36 is the ceiling. `int("zz", 36)` and `int("ZZ", 36)` both give 1295. Underscore separators and surrounding whitespace are tolerated in every base, exactly as in base 10, so `int(" ff_ff ", 16)` parses. ### Prefixes are allowed when they agree with the base A `0b`, `0o` or `0x` prefix may appear in the text when it matches the base you asked for. `int("0xff", 16)` is 255 and `int("0b1010", 2)` is 10. If the prefix disagrees with the base you get the ordinary parse failure: `int("0x1f", 10)` raises `ValueError`, because in base 10 the character `x` is not a digit. This matters when you accept identifiers copied from logs or configuration where the prefix may or may not be present — passing base 16 handles both `"ff"` and `"0xff"` with one call. ### Base 0 means "read it the way Python source would" `base=0` is the interesting case and the one interviews turn on. It does not mean base 10 and it does not mean "guess". It means: interpret the text using Python's own integer-literal rules. The prefix decides the radix — `int("0b1010", 0)` is 10, `int("0o17", 0)` is 15, `int("0x1f", 0)` is 31 — and with no prefix the text is read as decimal. Crucially, base 0 also inherits Python 3's rule that a decimal literal may not carry redundant leading zeros, so: ```python int("010", 0) # ValueError: invalid literal for int() with base 0: '010' int("010", 10) # 10 - explicit base 10 is happy to ignore the zero int("000", 0) # 0 - a run of zeros with no other digits is fine ``` Note what base 0 does *not* do: it does not resurrect the C convention where a leading zero means octal. It refuses the ambiguity rather than resolving it, and this is exactly why `base=0` is the right choice for a configuration file that wants to accept `0x1f`, `0b1010` and `31` from a human — and the wrong choice for a fixed-width numeric field where `"007"` is legitimate data. ### Going the other way There is no general "int to base-N string" function in the standard library. The three power-of-two radixes have builtins — `bin()`, `oct()` and `hex()` — and the same conversions are available as format specifications, which is usually the nicer form because you control width and prefix: `format(255, "x")` is `'ff'`, `f"{255:#06x}"` is `'0x00ff'`, and `f"{255:b}"` is `'11111111'`. For an arbitrary base you write the divmod loop yourself. Round-tripping is then `int(hex_text, 16)`. ### Choosing a base in real code Three rules of thumb are worth stating out loud in an interview. Pass an **explicit base** whenever the format is fixed by a protocol or a file format — a hex colour, a permission mask, a checksum — so a stray prefix or a wrong-radix value fails loudly. Pass **base 0** when the text is authored by a person who may reasonably write any Python literal form. Pass **no base at all** for ordinary decimal user input. And never build a parser that tries several bases in a loop until one succeeds: it turns a typo into a plausible wrong number, which is the failure mode explicit bases exist to prevent.