On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone <exar...@divmod.com> wrote: > - Show quoted text - > On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum <gu...@python.org> > wrote: >> >> On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva >> <sidnei.da.si...@gmail.com> wrote: >>> >>> On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum <gu...@python.org> >>> wrote: >>>> >>>> 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 > 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. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
