Why does int() refuse a 100,000-digit decimal string, and how is that limit changed?

### The limit itself Since **CPython 3.11** the interpreter refuses to convert between an `int` and its *decimal* text form when the numeral is longer than a configured number of digits. The default is **4300 digits**, and crossing it raises `ValueError: Exceeds the limit (4300 digits) for integer string conversion`. The current value is readable with `sys.get_int_max_str_digits()`, and `sys.int_info` reports both the default and the minimum value the limit may be set to (640). The limit is a property of the *text* conversion, not of the integer. Python's `int` is still arbitrary precision, and arithmetic on huge values is untouched. What is blocked is the pair of directions that cost more than linear time: * **Blocked:** `int(s)` and `int(s, 10)` (or any non-power-of-two base) on a long digit string; `str(n)`, `repr(n)`, `format(n)`, an f-string interpolation of `n`, and anything that serialises an int by way of its decimal text. * **Not blocked:** `hex(n)`, `bin()`, `oct()`, `int(s, 16)` and other power-of-two bases, `int.from_bytes()` and `int.to_bytes()`, comparisons, and all arithmetic. Binary-to-binary conversions are linear, so there is nothing to defend. ### Why the interpreter cares Converting between base 2 (how the integer is stored) and base 10 (how it is written) is not a linear operation — historically it was quadratic in CPython, and even with the subquadratic algorithms added later a big enough numeral burns real CPU inside a single opaque C call. That gives an attacker a very cheap amplification: a few hundred kilobytes of digits in a JSON body, a query parameter or a log line turns into seconds or minutes of interpreter time on one core, with no I/O to time out against. The cap was introduced in 3.11 and backported into security patch releases of 3.7 through 3.10 for precisely that reason; it converts an unbounded compute cost into an immediate, cheap exception. ### The symptom, and why it is easy to misdiagnose Consider a flight-schedule differ that ingests two daily schedule dumps and compares fields position by position. A field that should hold a small flight number arrives, in one feed, as a wall of digits — a corrupt export, or someone probing. On an older interpreter the symptom was an **intermittent timeout**: roughly one job in a thousand parked a worker for minutes on a single `int()` call, while the process sat at a **2.4 GB working set** from the two loaded dumps. Every dashboard pointed at memory pressure and GC, because the actual culprit was one C-level conversion that never yielded and never allocated much. On 3.14 the same input raises `ValueError` at the exact parse site, with the offending length in the message — a far better failure, and the reason the cap is worth having even in a service nobody attacks. ### What to do about it The wrong reflex is to treat the exception as a CPython bug and put `sys.set_int_max_str_digits(0)` at the top of the program. The setting is **interpreter-wide**, not per-call and not per-thread, so disabling it globally to make one legitimate code path work re-opens the hole on every untrusted path in the process. The ordered options: 1. **Bound the input first.** Untrusted numeric text should be length-checked and format-checked before conversion — a flight number is at most a handful of characters. Then the limit never fires and the rejection carries a useful message. 2. **Catch it at the boundary.** `ValueError` from `int()` on untrusted input is a client error: map it to a 400-style rejection, log the *length* and the field name, never the value. 3. **Raise the limit narrowly and deliberately** if a domain genuinely needs huge decimal numerals — cryptographic parameters, arbitrary-precision maths. Set it once at startup to a documented value with `sys.set_int_max_str_digits(n)` (n must be 0 or at least 640), or from outside the code with `-X int_max_str_digits=N` or the `PYTHONINTMAXSTRDIGITS` environment variable, and record why. 4. **Avoid decimal text altogether** for big values in hot paths. `int.to_bytes()` / `int.from_bytes()` and hexadecimal are linear and unrestricted, and are the right wire format for large integers anyway. ### The interview signal A senior answer distinguishes "the integer is too big" (never true — `int` has no size limit) from "its decimal *rendering* is too long"; names the operations on both sides of the fence; and treats the limit as a guardrail whose correct response is to bound the input, with raising the cap as a considered, scoped exception rather than a reflex.