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