Maintenance release? (Was RE: Variables different between .py and .pyc)

[Tim Peters]

[Aahz Maruch, on a proposed change to make .pyc/.pyo files store
 repr(float) instead of str(float)]

> Ouch.  This is the kind of situation where I was thinking that a
> distinction between "bugfix release" and "maintenance release" might
> be useful.  OTOH, it's hard to imagine a case where fixing this
> would make things worse....  I mean, really, what could this break?

Perhaps you have no experience with floating-point code <2/3 wink>?  Over the
years I've spent a good (distributed) half year of my life tracking down
gross problems in numerically naive algorithms triggered by measly 1-bit
differences.  This is a much bigger change than that.  Even a good algorithm
will return *different* results, and of course some people will scream
"different" == "broken".  You can't fix *any* bug that changes a result
without somebody feeling abused.

Trivial:

CONST = 0.0054794520547945206

i = int(CONST * 365)

The difference between current .pyc precision and proposed .pyc precision
there is the difference between i==1 and i==2.  Can you imagine why changing
an integer could break something?

Maybe this is more obvious (although it's really the same thing):

x = 9007199254740992.0
print long(x)

Stick that in a module and import it.  The first time you import it, it
should print

9007199254740992

Which isn't surprising -- the number happens to be exactly 2.**53.  Import it
a second time and it will print something closer to

9007199254740000

If people have been getting bad numeric approximations out of their float
literals in Python code for 10 years without knowing it, they've also been
fiddling their algorithms to compensate for the "mysterious problems" they
haven't tracked down.  Change what the literals denote, and the algorithmic
compensations are suddenly wrong too.

It's a mess.

nevertheless-it's-clearly-broken-and-there's-only-one-way-to-fix-it-ly
    y'rs  - tim