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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4