Signed zeros: is this a bug?

[Mark Dickinson]

On Mar 11, 12:13 pm, "Terry Reedy" <tjre... at udel.edu> wrote:
> "Dan Bishop" <danb... at yahoo.com> wrote in message
>
> news:1173629090.993914.55570 at 30g2000cwc.googlegroups.com...
> | On Mar 11, 9:31 am, "Mark Dickinson" <dicki... at gmail.com> wrote:
> | > I get the following behaviour on Python 2.5 (OS X 10.4.8 on PowerPC,
> | > in case it's relevant.)
> | >
> | > >>> x, y = 0.0, -0.0
> | > >>> x, y
> | > (0.0, 0.0)
> | > >>> x, y = -0.0, 0.0
> | > >>> x, y
> | >
> | > (-0.0, -0.0)
> || IIRC, float.__repr__ just does whatever libc does.  Have you tried
> | using printf("%g, %g", 0.0, -0.0) in a C program?
>
> Detailed FP behavior like this is system (and yes, libc) dependent.  On
> WinXP
> IDLE 1.1.3>>> x,y = 0.0, -0.0
> >>> x,y
> (0.0, 0.0)
> >>> x,y = -0.0, 0.0
> >>> x,y
> (0.0, 0.0)
> >>> -0.0
>
> 0.0
>
> Terry Jan Reedy

Interesting.  So on Windows there's probably no hope of what I want to
do working.
But on a platform where the C library does the right thing with signed
zeros, this
behaviour is still a little surprising.  I guess what's happening is
that there's
some optimization that avoids creating two separate float objects for
a float literal
that appears twice, and that optimization doesn't see the difference
between 0. and -0.

>>> x, y = 0., -0.
>>> id(x) == id(y)
True

jim-on-linux's solution works in the interpreter, but not in a script,
presumably because we've got file-wide optimization rather than
line-by-line optimization.

#test.py
x = -0.0
y = 0.0
print x, y
#end test.py

>>> import test
-0.0 -0.0

Mark