Signed zeros: is this a bug?

[Gabriel Genellina]

En Sun, 11 Mar 2007 15:26:01 -0300, Alex Martelli <aleax at mac.com> 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