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.