Why does int('3.0') raise ValueError while int(3.0) returns 3?

### Two different jobs behind one name `int()` is a constructor whose behaviour depends entirely on the *type* of what you hand it, and the two behaviours have almost nothing in common. Confusing them is what makes `int('3.0')` surprising. **Given a string, `int()` is a parser.** It accepts exactly the grammar of an integer literal in the requested base and nothing else: optional surrounding whitespace, an optional `+` or `-` sign, then one or more digits with optional single underscores *between* digits. There is no fractional part in that grammar and no exponent part. So all of these raise `ValueError` with the message `invalid literal for int() with base 10: '...'`: ```python int("3.0") # a dot is not part of the integer grammar int("3e2") # nor is an exponent int("") # no digits at all int("1__0") # doubled underscore int(" 4 2") # embedded whitespace ``` The strictness is deliberate. `int(s)` is the function that asserts "this text is a whole number"; if it quietly accepted `'3.9'` and returned `3`, a data-entry error would become a silently wrong answer instead of a loud failure. The things it *does* forgive are cosmetic only: leading and trailing whitespace (`int(" 42\n")` is 42), a sign, and PEP 515 digit separators (`int("1_000")` is 1000, though `int("_1000")` is not). `bytes` and `bytearray` are accepted on the same terms, so `int(b"42")` works. **Given a number, `int()` is a converter.** `int(3.9)` is `3` and `int(-3.9)` is `-3`. It **truncates toward zero**: it discards the fractional part rather than rounding to nearest and rather than flooring. The distinction is invisible on positive values and bites on negative ones, which is where interviewers probe. Two float values have no integer to convert to, and each has its own error: `int(float("nan"))` raises `ValueError` and `int(float("inf"))` raises `OverflowError`. For a class of your own, `int()` looks for `__index__` first (the lossless, "I *am* an integer" protocol) and falls back to `__int__`. ### The practical consequence: parsing user text Because the string path has no notion of a decimal point, text like `"3.0"` has to be routed through the float parser first: ```python value = int(float(user_text)) ``` That composition is honest about what it does — `float()` parses decimal text, `int()` throws the fraction away — but it carries two costs a senior candidate should name. First, it also accepts `"3.9"` and yields `3`. If the requirement is really "must be a whole number", validate rather than truncate: parse with `float()`, check `float.is_integer()`, and reject otherwise. Truncation is a decision; make it on purpose. Second, it loses precision on long numerals. A binary64 float carries roughly 15-17 significant decimal digits, so `int(float("12345678901234567890"))` is *not* the number that was typed, while `int("12345678901234567890")` is exact — Python's `int` is arbitrary precision, and the string path never goes through a float. When the text is known to be a whole number, always parse it with `int()` directly; the `float()` detour is only for text that genuinely carries a decimal point. ### How to fail well `int()` raises `ValueError` and nothing else for malformed text, so a boundary that parses untrusted input has an easy shape: ```python try: quantity = int(field) except ValueError: reject(f"expected a whole number, got {len(field)} characters") ``` Catch `ValueError` specifically at the point of parsing, convert it into a domain-level rejection, and avoid logging the raw value if it is untrusted. A blanket `except Exception` around a conversion is a red flag: it swallows `TypeError` (which means you passed the wrong *type*, a programming bug, not bad data) and, on very long digit strings, the `ValueError` that CPython raises for a different reason entirely. ### What an interviewer is listening for The good answer states the parser/converter split in one sentence, gives the truncation-toward-zero rule with a negative example, and reaches for `int(float(s))` while naming its two costs. The weak answer says "`int()` rounds" — it does not — or claims `int('3.0')` returns 3 because "Python is dynamically typed", which confuses type flexibility with parsing rules.