[Python-Dev] draft pep: backwards compatibility

[glyph at divmod.com]

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

>>I've taken a stab at this myself in the past while defining a policy 
>>for
>>Twisted

>Yes, that's helpful. Thanks.

Glad you found it useful.
>>The questions that follow might seem satirical or parodic but I am
>>completely serious and each of these terms really does have a variable
>>definition.
>
>And will always no matter what we do. It's how natural language works.

Well, one cannot proceed from the informal to the formal by formal 
means.  I'm pretty sure we can nail down the definitions of these terms 
for the scope of Python core development.
>>What is "behavior"?  Software is composed of behavior.  If no behavior
>>changes, then nothing can ever happen.

>I mean that if you pass X and Y into a function and get Z in 2.6, then
>you should be able to get Z from passing X and Y in 2.7 even if
>there's a new argument that returns Z' if you pass True to it.
>(Obviously, this is somewhat simplified, but I hope it helps.)

This definition only makes sense if the interesting thing about a 
function is its return value, and if the only sort of thing you have are 
functions.  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.)
>>How do you propose to measure the benefit to breakage ratio?  How do 
>>you
>>propose to define "trivial" to fix?  Most projects, including Python,
>>Twisted, Django, and Zope, have an ever-increasing bug count, which 
>>means
>>that trivial issues fall off the radar pretty easily.
>
>Well, if you're tests aren't failing from it, is it an incompatibility?

Well, let's say the tests do fail from it.  Right now, even Twisted 
trunk still doesn't *quite* support Python 2.6, but only on Windows, due 
to stricter checking of the 'mode' argument for files.  But this failing 
test is just not that high priority, so our recommendation is "don't use 
python 2.6 yet on Windows, 2.5 works fine".  My point is that triviality 
is a matter of perspective :).  Eventually somebody will get around to 
it, but 2.6 has been out for a while now.
>>There are a very large number of users of Python, the large percentage 
>>of
>>whom do not read python-dev.  A posting on python-list is likely to 
>>provoke
>>an unproductive pile-on.  I suggest a dedicated list, which should 
>>ideally
>>be low traffic, "python-incompatible-announce", or something like 
>>that, so
>>that *everyone* who maintains Python software can subscribe to it, 
>>even if
>>they're not otherwise interested in Python development.
>
>And that won't generate a pile-on?

Well, the etiquette for that specific list could be "keep this low- 
traffic unless you have a serious problem with this change".  Or, better 
yet, make it an announce-only list: the pile-on can still happen on 
python-list, but only the results of the discussion will be announced on 
the incompatible-announce list.

The point is, the notifications about compatibility are really 
important, and sometimes people need to offer feedback about them, but 
not everyone who needs to know about the changes needs to hear about the 
feedback.