[Random832 <random832@fastmail.com>] [various bits of pushback, which all basically boil down to this one:}
... That is nonsense. "exactly representable" is a plain english phrase and has a clear meaning that only involves the actual data format, not the context.
The `decimal` module implements a very exacting standard, and the words it uses have technical meanings precisely defined by the standard. The intended meanings are what I've said they are. It's futile to insist that those match your "plain English" meanings. If you believe the docs should be clearer about that, go for it. But, no, they won't be changed to use technical phrases in ways that contradict what the standard intends by them. For example,
Even though it's part of the *model* used for calculations, it's not relevant to the *representation*, so it has no effect on the set of values that are exactly representable. So, "if the exact result is exactly representable that's what you get" is plainly false.
No, under the standard it's plainly true. The key word is "result". The _result_ of virtually decimal operation is required to round to context precision. It's your harping on "representation" that's irrelevant to this. Else, as already explained, the meaning of the "inexact" flag/signal would be incomprehensible.
Nonsense. The meaning of the inexact flag means that the module *chose* to discard some information.
No "choice" involved: under the standard it's mandatory. If you want decimal arithmetic following other rules, that's fine, but then you're not talking about Python's `decimal` module anymore. And that's the last I have to say about this.