[Python-ideas] Python Numbers as Human Concept Decimal System

[Paul Moore]

On 8 March 2014 23:36, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> This reminded me a discussion we had with Mark Dickinson on the bug tracker:
> "When a user is entering 0.6112295, she means 0.6112295, not
> 0x1.38f312b1b36bdp-1 or
> 0.61122949999999998116351207499974407255649566650390625 which are exact
> values of the underlying binary representation of 0.6112295."

However, when a user enters 0.6112295, she presumably *also* means she
wants a float value (assuming she understands how literals in Python
work). What the user *doesn't* necessarily realise is that those two
desires are mutually contradictory (there *is* no float value for the
exact value 0.6112295). So the question becomes, what should we do
when the user asks for two mutually-incompatible things.

One option is to raise an exception. I presume everyone agrees that
this is not a sensible option :-) [0.1 is a syntax error, but 0.5 is
OK...]
Another option is to fail to satisfy the user's desire for exactly
0.6112295. But do the best we can given the limitations of floats.
That's current behaviour.
A third option would be to fail to satisfy the user's implied desire
for a float:
  - either by always giving a Decimal (which is a variation on the
original "decimal as the default non-integer type" proposal)
  - or by giving an exactly equivalent float if possible but a Decimal
otherwise (which means seemingly-similar literals have different
types)

The only one of these that feels palatable to me is the current behaviour.

The problem of course is that what the user *actually* wants is
context-sensitive behaviour - they don't *see* a float being passed to
a constructor, but rather a Decimal (or timedelta, or whatever)
literal being written using a slightly-clumsy functional notation.
That's why explicit decimal literals are a good fit for the actual
user issue here. (It also hints at a benefit to more general
user-defined literals, but let's not go there :-))

Paul