On 06:51 pm, exar...@divmod.com wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum <gu...@python.org>
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone
<exar...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
