[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
glyph at divmod.com
glyph at divmod.com
Wed Mar 4 20:44:46 CET 2009
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>
>>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
>the 2.6 series in this case (sorry if it appeared earlier in this
>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.
More information about the Python-Dev