En Sun, 11 Mar 2007 15:26:01 -0300, Alex Martelli <[EMAIL PROTECTED]> escribió:
> Or maybe we should give up ever storing -0.0 in the tables
> of constant and ALWAYS have "0.0, unary-minus" wherever it appears (that
> would presumably require working on the AST-to-bytecode visitors that
> currently work ever-so-slightly-differently for this specific
> troublespot in the C-coded version vs the Python-coded one...).
I think that way is the less intrusive, doesn't rely on a particular FP
implementation, and the more likely to be accepted.
Looking at ast.c, the culprit is some optimization in ast_for_factor, line
1506
/* If the unary - operator is applied to a constant, don't generate
a UNARY_NEGATIVE opcode. Just store the approriate value as a
constant. The peephole optimizer already does something like
this but it doesn't handle the case where the constant is
(sys.maxint - 1). In that case, we want a PyIntObject, not a
PyLongObject.
*/
After the long "if", I would use parsenumber(STR(pnum)) and check the type
and value of the resulting object; if it's a float and 0.0, skip the
optimization and continue below as a normal case.
Unfortunately I'm not able to compile and test the code right now, so I
can't provide an actual patch. (At least, not until tuesday). But I hope
this simple comment is useful anyway...
(I cannot find peephole.c on the source distribution for Python 2.5, but
you menctioned it on a previous message, and the comment above refers to
the peephole optimizer... where is it?)
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
