[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
Guido van Rossum
guido at python.org
Wed Mar 4 19:46:28 CET 2009
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> - Show quoted text -
> On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum <guido at python.org>
>> On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
>> <sidnei.da.silva at gmail.com> wrote:
>>> On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum <guido at python.org>
>>>> Sounds like it's not so much the code that's future proof but the
>>>> process used for evolving it. That seems to be missing for asyncore.
>>> Turning the issue around a bit, has anyone considered polishing up the
>>> current fix to restore it's backwards compatibility, instead of
>>> starting a discussion about a full-blown replacement?
>>> I think that would be enough for most asyncore users (or even the
>>> couple few affected) for the moment, and then we can think about a
>>> possible future replacement.
>> If it can be done while maintaining backwards compatibility with both
>> the 2.6 version and the pre-2.6 version, that would be great of
>> course! But can it?
> Is it really necessary to retain compatibility with the Python 2.6
> version? Python 2.6.0 and Python 2.6.1 contain a regression (as
> compared to basically all previous versions of Python) which prevents
> asyncore-based programs which are years old from working on them.
> Restoring the pre-2.6 behavior will fix these old, presumably stable,
> widely used programs for users who install 2.6.2 and newer.
> The downside (which you were imagining, I'm sure) is that any new
> software developed against the Python 2.6.0 or 2.6.1 behavior will
> then break in 2.6.2 and later. While this is unfortunate, it is
> clearly the far lesser of two evils. The choice must be made, though.
> Either leave old software broken or break new software. Just because
> the "leave old software broken" choice is made through inaction doesn't
> make it the better choice (though obviously since it requires action,
> someone will have to do it, and I'm not volunteering - if inaction is
> the choice because no one wants to do the work, fine, but that's a
> different motivation than avoiding breaking newly written software).
> 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
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.
asyncore.python_25_compat = True
Note that this "API" is designed to work in 2.5 as well. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev