[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[glyph at divmod.com]

On 06:51 pm, exarkun at divmod.com wrote:
>On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum <guido at python.org> 
>wrote:
>>On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone 
>><exarkun at divmod.com> wrote:

>>>So, as a disinterested party in this specific case, I'd say revert to
>>>the pre-2.6 behavior.

>>Sorry, but I really do think that we should maintain backward
>>compatibility *within* the 2.6 series as well.

>But why?  The argument I made had the objective of minimizing developer
>effort.  What's the objective of maintaining backward compatibility 
>within
>the 2.6 series in this case (sorry if it appeared earlier in this 
>thread
>and I missed it)?

Python's compatibility policy dictates that compatibility between micro- 
version releases be maintained *extremely* carefully.

As you all well know, normally I'd be strongly in favor of adhering to 
such a policy.  However, the ostensible purpose of the policy here is 
that users can *always* install micro-version upgrades to get bugfixes 
and security fixes, without worrying about compatibility upgrades.

Maintaining compatibility with the 2.6.x version of asyncore presupposes 
that *someone* has written some software against that version of 
asyncore and it might break if they installed an upgrade, though.  If 
that's the case - if there's even one person who has written or run any 
asyncore software against the version in 2.6 - then I think maintaining 
bug-for-bug compatibility is important.

However, my guess - and I'm assuming that JP was thinking the same thing 
- is that literally nobody has done that, or even *would* ever do that, 
so there's no software anywhere in the world that would break.  asyncore 
is relatively unpopular (thanks in part to the excellent alternatives 
:-)); its major users are the same people who have already complained.

Maybe it's too late to do something like this for 2.6, or even 3.0, but 
I've thought on a few occasions that projects (both Python and Twisted, 
at least) could use a special very-low-traffic policy-deviations mailing 
list for "We *REALLY* don't think this is going to ever break anything 
anyone has actually done, but just to be sure..." notifications for 
situations like this.  The implications being that (A) _everyone_ who 
uses the software should subscribe, and (B) if anyone ever responded to 
a message, the deviation wouldn't take place.

Anyway, I'm also a disinterested observer, so please don't take this as 
a strong endorsement of doing the fix in 2.6; the set-an-attribute-to- 
fix-it idea is fine by me too.  I thought I'd lay out the reasoning for 
violating an otherwise extremely reasonable policy, though.