On 10 Mar 2014 21:06, "Steven D'Aprano" <steve@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@python.org> wrote:
> > > On Sun, Mar 9, 2014 at 1:07 PM, Oscar Benjamin <oscar.j.benjamin@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@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/