
Guido van Rossum <guido@python.org> wrote:
On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone <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: [snip]
So, as a disinterested party in this specific case, I'd say revert to the pre-2.6 behavior. It does less harm than leaving the current behavior.
Sorry, but I really do think that we should maintain backward compatibility *within* the 2.6 series as well. If that makes it impossible to also maintain the 2.5 behavior, perhaps some flag could be added to restore 2.5 compatibility, e.g.
import asyncore asyncore.python_25_compat = True
Note that this "API" is designed to work in 2.5 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)?
The same as always. We don't change APIs in bugfix releases.
OK, seems reasonable. But in this case, isn't the broken API the bug that's being fixed? Do we need a different way to fix broken APIs in bugfix releases? Bill