When a Python import receives a decimal amount as text, construct Decimal directly from that text rather than converting it through float. Then apply a documented rounding rule at the correct stage. This preserves the decimal input value; it does not decide the business rule for tax, invoice totals or currency precision.
The important distinction is between Decimal("2.675") and Decimal(2.675). The first represents the supplied decimal text. The second converts an already-created binary floating-point value, including its approximation. Python’s official documentation explicitly describes float-to-Decimal conversion as exact conversion of that float’s value, not recovery of the original typed decimal.
Keep decimal text intact at the input boundary
Suppose a CSV export contains a unit price of 2.675 before rounding. For this deliberately hypothetical example, the application specification requires two decimal places with ties rounded away from zero. Preserve the field as a string until it reaches the Decimal constructor.
Do not insert a float conversion merely because the field looks numeric. Also avoid treating Decimal(str(existing_float)) as a general repair for old data. It converts the float’s displayed string, which may no longer contain the original input digits. If those original digits matter, recover the source text or establish an explicit migration policy.
This tutorial assumes plain decimal text, not currency symbols or locale-formatted thousands separators. Decimal construction is not a complete input schema: if your application disallows scientific notation, underscores, surrounding whitespace or negative values, validate those requirements separately.
Run an explicit two-place rounding example
The following Python 3 example uses only the standard library. It isolates its arithmetic context, rejects special non-finite values and prints both the intended text conversion and the float-conversion comparison. The chosen rounding mode is an example requirement, not a universal rule for money.
from decimal import Decimal, ROUND_HALF_UP, localcontext
raw_amount = "2.675"
with localcontext() as ctx:
ctx.prec = 28
amount = Decimal(raw_amount)
if not amount.is_finite():
raise ValueError("Amount must be finite")
cents = Decimal("0.01")
rounded = amount.quantize(cents, rounding=ROUND_HALF_UP)
from_float = Decimal(2.675).quantize(
cents, rounding=ROUND_HALF_UP
)
print(f"from text: {rounded}")
print(f"from float: {from_float}")
For this example the text path prints 2.68 and the float path prints 2.67. Both use the same quantize operation and rounding mode; they start with different numeric values. The comparison demonstrates an input-conversion difference, not random behaviour in rounding.
The local precision of 28 significant digits comfortably supports this small example. It is not an unlimited capacity setting. Production inputs with many digits or large exponents need defined size limits and deliberate context/error handling. Increasing precision later cannot reconstruct digits already lost through an earlier float conversion.
Choose the rounding stage as well as the mode
Python documents quantize as rounding to a fixed exponent. Using 0.01 requests hundredths, but that does not establish whether you should round each line, each tax component or only the final total. Those choices can produce different totals even when every calculation uses Decimal.
Write the required rule down before replacing existing arithmetic. Confirm the supported currency, permitted input range, treatment of negative adjustments and whether supplied amounts are already rounded. Preserve the original input alongside transformed results when your audit requirements call for it.
Do not use global context changes casually in a shared application. A local context makes this example’s precision choice explicit without leaving that precision installed for unrelated later calculations. It still does not make other code’s arithmetic policy correct.
Reject invalid and special values deliberately
A successful Decimal constructor does not prove the input is an ordinary payable amount. Decimal supports NaN and infinity, which is why the example checks is_finite(). Malformed input can raise a decimal exception under the active context; handle that at your real import boundary rather than silently substituting zero.
If you also export API data, see the separate tutorial on rejecting NaN and Infinity in Python JSON. JSON serialization and Decimal arithmetic are different boundaries: solving one does not automatically configure the other.
Review checklist and FAQ
- Keep the original decimal field as text until construction.
- Define valid syntax, finite-value checks and magnitude limits.
- Specify rounding mode, decimal places and rounding stage.
- Test positive and negative ties against approved expected results.
- Compare imported records and totals before replacing production output.
Is ROUND_HALF_UP always correct? No. It is the explicit hypothetical policy here. Select the rule required by your application.
Does Decimal eliminate all rounding? No. Arithmetic still uses context precision, and quantize deliberately rounds. Read the checked Python decimal documentation for conversion, contexts, special values and rounding modes.
Educational-use notice: Test carefully before using this workflow in production. The site owner is not responsible for misuse, damage, data loss or production issues. Validate real business requirements before changing calculation or import behaviour.
