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

[Nick Coghlan]

On 10 Mar 2014 21:06, "Steven D'Aprano" <steve at pearwood.info> wrote:
>
> On Mon, Mar 10, 2014 at 10:07:11AM +0000, Oscar Benjamin wrote:
> > On 9 March 2014 20:39, Guido van Rossum <guido at python.org> wrote:
> > > On Sun, Mar 9, 2014 at 1:07 PM, Oscar Benjamin <
oscar.j.benjamin at gmail.com> wrote:
> > >>
> > >> The problem though is with things like +3.14d or -3.14d. Python the
> > >> language treats the + and - signs as not being part of the literal
but
> > >> as separate unary operators.
>
> Is that still true? Possibly the peephole optimizer has changed the
> situation?
>
> Using Python 1.5:
>
> >>> from dis import dis
> >>> dis(compile("-5", "", "single"))
>           0 SET_LINENO          0
>
>           3 SET_LINENO          1
>           6 LOAD_CONST          0 (5)
>           9 UNARY_NEGATIVE
>          10 PRINT_EXPR
>          11 LOAD_CONST          1 (None)
>          14 RETURN_VALUE
>
>
> but using Python 2.4:
>
> py> dis(compile("-5", "", "single"))
>   1           0 LOAD_CONST               0 (-5)
>               3 PRINT_EXPR
>               4 LOAD_CONST               1 (None)
>               7 RETURN_VALUE
>
> (versions more recent than 2.4 also use a constant).

It actually makes the discrepancy worse, rather than better - the optimiser
is just doing constant folding at compile time, so it would just be
rounding using the context that applied at compile time. That context
dependence creates problems for the entire *notion* of constant folding
decimal literals - you can't constant fold them at compile time at all,
because the context may be wrong.

I think users of decimal literals will just need to deal with the risk of
unexpected rounding, as the alternatives are even more problematic.

Cheers,
Nick.

>
>
> > >> This is unimportant for int, float and
> > >> imaginary literals because there unary + is a no-op and unary - is
> > >> exact. For decimal this is not the same as +Decimal('3.14') is not
the
> > >> same as Decimal('+3.14'):
> >
> > > Any solutions you are going to come up with would cause other
anomalies such
> > > as -(5d) not being equal to -5d. My vote goes to treating + and - as
the
> > > operators they are and telling people that if they want a negative
constant
> > > that exceeds the context's precision they're going to have to use
> > > Decimal('-N'), rather than adding a terrible hack to the parser (and
hence
> > > to the language spec).
> >
> > I think it's reasonable that -(5d) not be equal to -5d.
>
> Did you leave the word "not" out of that sentence? :-)
>
> I don't think that it is reasonable for -(5d) to not equal -5d. I think
> that's an awful interface, and terribly surprising. I don't think that
> there are any situations were an otherwise redundant pair of parens
> changes behavious. E.g. x*(y) is the same as x*y.
>
> (Parens are sometimes used to disambiguate syntax or change precedence.
> That's different, since the parens aren't redundant.)
>
> Considering that the motivation for this change is to make it easier for
> newbies and numerically naive users, I really do not relish having to
> explain to newbies why -5d and -(5d) are different.
>
>
> --
> Steven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140310/64852efb/attachment.html>