[Python-Dev] draft pep: backwards compatibility

[Benjamin Peterson]

2009/6/19  <glyph at divmod.com>:
> On 02:09 pm, benjamin at python.org wrote:
>> 2009/6/19  <glyph at divmod.com>:
>>> 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.)

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

>>>
>>> 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.

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


>>> 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.

I think that's a fine idea, but the PEP is dealing with policy as our
mailing list infrastructure is now.


-- 
Regards,
Benjamin