[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.535.2.107

[Tim Peters]

[Andreas Jung]
> So what is the sense  to have a policy?  ..and what are the rules
> to break the policy ? :-)

I can explain the rule used for Python bugfix releases, but you won't be
happy with it <wink>:  Every change has pros and cons.  No change is made in
any release unless the pros exceed the cons.  For a bugfix release, the
policy against a change in visible behavior adds a big con against such
changes.  The pros have to strong then to overcome that, much more so than
in a non-bugfix release, and/or the other cons have to be very weak.

For example (and these are rare!), in Python 2.2.3 (not yet released),
Python will support os.fsync() on Windows for the first time.  This is
really a new feature, and can certainly change the behavior of programs that
currently branch on hasattr(os, 'fsync').  That con is thought to be very
weak, since no example of such code is known, and it's an unlikely thing for
sane code to be doing.  There are other things against it (new docs, new
tests, possibly unintended behavior on "Windows-like" systems we can't
test -- any change carries several risks of breakage), but they're minor
compared to the risk of primary breakage, and the latter is judged as
insignificantly unlikely.

The pro is that Zope Corp's FileStorage needs some form of fsync() to
improve reliability in the face of Windows unreliability, and there's no way
in 2.2.2 to get at the Windows flavor of fsync() from Python (not short of
installing the win32 extensions and using the native Win32 API to commit
system buffers to disk).

The details there didn't matter, the point is that such decisions always pit
pros and cons against each other, and are always arguable (e.g., maybe you
don't think FileStorage reliability is important on Windows, or maybe
someone else has built a product relying on playing hasattr tricks with the
os module).

The sense in having a policy is to favor one usually-right outcome in the
absence of strong argument against it.  The rule for violating the policy is
that a strong argument succeeds.  Success or failure in the latter is the
outcome of a social process, like the one we're engaged in now.  It probably
would have been better if Chris had discussed the tradeoffs before
committing the change, though.  "Retroactive discussion" happens in Python
development too, and I'd say there's about a 50-50 chance that such changes
get reverted there, usually when someone points out a specific con the
committer wasn't aware of, or didn't value as highly as most people.