This all seems a pretty artificial argument.

In plain English, "1/3" is not exactly representable in decimal form, but something like 0.1111111111111111111111111111 * 0.22222222222222222222222222 *is* (assuming the inputs are what they appear).

Since the spec clearly means to say "exactly representable in the (current or given) context's precision" that phrase (or something non-empty like it) should just be added to the docs and the argument is over.

This is not the only place where Python's docs are vague even though the code is careful (e.g. the docs for 'typing' and 'asyncio' could use work, to mention some that I personally care about). Most places that take strings are unclear about whether they also take bytes. Some places that take files are unclear about whether they take file names or file objects (a.k.a. streams). And so on.

On Wed, Oct 14, 2020 at 6:20 PM Steven D'Aprano <> wrote:
On Thu, Oct 15, 2020 at 11:28:36AM +1100, Chris Angelico wrote:

> Neither 1/3 nor sqrt(2) can be *exactly represented* as a decimal
> fraction.

Indeed, I am very aware of that, and in fact they were precisely the
examples I gave to question Random's assertion that inexact rounding is
something that the module chooses to do.

> I don't really understand your complaint here. The plain English
> interpretation of "exactly representable" is, within margin of error,
> a perfectly representable concept. (The "margin of error" here is
> that, barring infinite RAM, there will always be *some* limit to the
> precision stored.)

It's not *my* complaint, I'm not making any complaints! Random is, or
was, complaining about the way Tim was using "exactly representable". As
far as I can tell, Tim, you and me all agree that exactly representable
for Decimal should be read as "within the current context's precision",
but Random apparently disagrees. I'm not quite sure what he thinks it
should be read as, but I guess it might be related to honouring the
implicit precision of the Decimal object itself.

> > (To be honest, I was surprised to learn that the context precision is
> > ignored when creating a Decimal from a string. I still find it a bit odd
> > that if I set the precision to 3, I can still create a Decimal with
> > twelve digits.)
> The context is used for arithmetic, not construction.

Ack. I'm not saying it's wrong to do so, only that it surprised me when
I first discovered it.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

--Guido van Rossum (
Pronouns: he/him (why is my pronoun here?)