Why does decimal.Decimal(0.1) differ from decimal.Decimal('0.1')?

### Two different inputs, two different meanings `decimal.Decimal` accepts several argument types, and the interesting difference is between a string and a float. Given a **string**, the constructor parses the characters. `Decimal('0.1')` becomes a coefficient of 1 with an exponent of -1 - exactly one tenth, with a scale of one decimal place. What you typed is what you get. Given a **float**, the constructor converts the float's actual value with no loss at all. That sounds reassuring until you remember what the float actually holds. `0.1` written in Python source is not one tenth; it is the binary64 value nearest to one tenth. Every binary fraction has a finite decimal expansion, so that value can be written out exactly in base 10, and it takes 55 digits: `0.1000000000000000055511151231257827021181583404541015625`. `Decimal(0.1)` shows you those digits. The conversion is faithful; the *input* was already not one tenth. So `Decimal(0.1) == Decimal('0.1')` is False, and so is `Decimal('0.1') == 0.1`, while `Decimal('0.5') == 0.5` is True - a half is a power-of-two fraction and survives binary exactly. ### Why the constructor does not round A natural objection: the default context allows 28 significant digits, so why does the constructor hand back 55? Because construction is not an arithmetic operation. The decimal specification treats conversion into the type as exact, and CPython follows it: neither `prec` nor the rounding mode is consulted by `Decimal(...)`. `Decimal('123456.789')` stays `123456.789` even under a context with `prec` set to 6. Precision is applied by *operations*. Adding zero, or applying unary plus, runs the value through the context and rounds it: under `prec = 6`, `Decimal('123456.789') + Decimal(0)` gives `123457`. If you want construction itself to respect a context, call that context's own constructor: `Context(prec=3).create_decimal('123456.789')` yields `1.23E+5`. ### The explicit spellings `Decimal.from_float(0.1)` is a classmethod that does exactly what passing the float to the constructor does; it exists to make the intent unmistakable in code that really does want the float's true value - for instance when you are *inspecting* a float rather than computing money with it. The same information is available from `float.as_integer_ratio()`, which returns the exact numerator and denominator, from `float.hex()`, and from `fractions.Fraction(0.1)`, which prints `3602879701896397/36028797018963968`. All four are views of the same underlying fact. ### Where this actually bites The bug in production is almost never someone typing `Decimal(0.1)` in a source file. It is a value that arrives from somewhere as a float and is converted late: a JSON payload decoded with the standard decoder, a CSV column passed through `float()`, a database driver configured to return floats, a configuration value read as a number. By the time your code sees a float, the intended decimal value is gone; wrapping it in `Decimal` preserves the damage with great fidelity rather than repairing it. The fixes all live at the boundary. Decode JSON numbers as strings, or hand the decoder a hook that builds Decimals from the raw text. Read CSV fields as text and construct from the text. Configure the database adapter to return the exact type. Only when none of that is possible do you convert a float, and then you must round explicitly and consciously - and record that you did. ### The seductive wrong fix Candidates often propose `Decimal(str(0.1))`. It happens to work for one tenth, because `repr` of a float prints the shortest string that round-trips to the same float, and for 0.1 that string is '0.1'. But it is not a repair: it is a guess that the shortest round-tripping string is the value somebody originally meant. Feed it the result of a float computation - a value that has already drifted - and it faithfully preserves the drift in a shorter form. It also silently changes the number of significant digits you carry. Use it as a last-resort conversion at a boundary you cannot control, never as the reason it is safe to let floats into money code. ### What to say in the interview One sentence for the mechanism ('the float is converted exactly, and the float is not one tenth'), one for the design reason ('construction is exact by specification, precision applies to operations'), and one for the consequence ('so parse strings at the boundary; a late conversion cannot recover what the literal already lost').