[Python-Dev] draft pep: backwards compatibility

[glyph at divmod.com]

On 19 Jun, 09:08 pm, benjamin at python.org wrote:
>2009/6/19  <glyph at divmod.com>:
>>On 02:09 pm, benjamin at python.org wrote:
>>>2009/6/19  <glyph at divmod.com>:

>> What about side-effects, or exceptional conditions?  What about
>>interactions with subclasses?  (Changing a class in a library from 
>>old-style
>>to new-style has serious repercussions, as MRO conflicts can result in
>>applications that subclass it.)

>I've added a little more about this to the PEP. See what you think.

Finally had a chance to take a look.  It's a big improvement, certainly: 
much more specific.  Although I think I have a few quibbles with the 
wording.

For one thing, I don't like the use of the word "reasonable".  Everybody 
thinks *their* exception to the rules is reasonable, but nobody else's 
is.  Besides, if the BDFL thinks a change is really reasonable, do you 
think a PEP is going to stop him? :)

For another, I think it's actually a bit too strict, as worded.  The 
side-effects of a function includes the warnings that it emits; any 
method-call can have side-effects, so you can't change an algorithm *at 
all*.  The only side-effects that I think are important are the ones 
that get invoked on objects that an application gets to inject 
somewhere, or inspect later via a public API.

The word "releases" also needs to be qualified.  Most importantly, 
minor-version and micro-version releases need to be described 
distinctly.

Finally, the PEP should mention its participation in the universe of 
compatibility process PEPs.  It should describe its relationship to at 
least some of PEP 3002, 291, 5, 6, 2, 3001, and 384.
>>My point is that triviality is a matter of perspective :).

>I understand. I think we will just have to provide guidelines for
>triviality and decide on a case by case basis.

A simple litmus test, or some examples, of triviality would be helpful.
>>the pile-on can still happen on python-list, but
>>only the results of the discussion will be announced on the
>>incompatible-announce list.
>
>I think that's a fine idea, but the PEP is dealing with policy as our
>mailing list infrastructure is now.

Hmm... well, maybe everybody should just run their tests against Python 
trunk.  The commits list is a reliable notification mechanism for 
potentially incompatible changes ;-).  Perhaps it would be good to 
mention this specifically in the PEP?  For example, "third party 
projects may request that an incompatible change be reverted, by 
providing evidence of tests failing on x.y+1 that passed on x.y, where 
the code in question does not rely on any details not specified as 
'public' in the section above"?

If more projects did this when there *was* a problem, then it would 
actually be a lot easier to break the policy with confidence. With an 
incompatible change, you could know, "we checked it in, and nobody 
complained".  Whereas right now is nobody complains it's more likely 
that nobody is paying attention.