On 10 Mar 2014 21:06, "Steven D'Aprano" firstname.lastname@example.org wrote: >
On Mon, Mar 10, 2014 at 10:07:11AM +0000, Oscar Benjamin wrote:
On 9 March 2014 20:39, Guido van Rossum email@example.com wrote:
On Sun, Mar 9, 2014 at 1:07 PM, Oscar Benjamin firstname.lastname@example.org 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.
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 xy.
(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.
Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/