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

[Carlos Ribeiro]

At 03:58 08/05/01 -0400, Tim Peters wrote:
>[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.

Tim, I'll take my risk and disagree with you <wink-and-duck>. This will be 
a problem anyway with any new release of Python that changes it, so anyone 
who upgrades to the newest version should be advised. If your code depends 
on wrong behavior, it is wrong, and it needs to be fixed. Just post a 
notice on the README file...

Anyway, there are some alternatives:

1) A command line option could be included to signal the compiler to use 
the old behavior - there is not need for a __future__ issue on this one. 
It's just a matter of "compiling" (generating the .pyc) using the command 
line option. The generated .pyc is a stable representation, at least until 
you edit your code. You could even mix old and new behavior (in different 
modules, of course!) into the same application. Of course, including a new 
command line option is something that deserves discussion as part of the 
what-goes-on-a-maintenance/bugfix-build.

2) A warning could be generated whenever a float constant that triggers 
this problem is detected. This could be coupled with the command line 
option. Optionally, the maintenance release could keep the old behavior, 
but warn that the future versions may give different results in this case. 
The user would have a simple option: rewrite the constant using a less 
precise value, to keep the behavior after the change. The warning message 
could even show the number to be used, for example:

0.0054794520547945206 -> 0.00547945205479

Anyway, I keep thinking that this is a nice case to test what should (or 
not) go into a maintenance/bugfix release :-) In this regard, I'm heavily 
influenced by Cisco's release practice. They keep doing releases of the 
older versions for two reasons - supporting new hardware and fixing bugs. 
In fact, they go to extremes to do it. I don't see the need to make nearly 
as many releases as they do - it's a nightmare when you're searching for 
the release/feature set that you want - but at least they are working to 
keep older versions reasonably up-to-date.


Carlos Ribeiro