
On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum <guido@python.org> wrote:
On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva <sidnei.da.silva@gmail.com> wrote:
On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum <guido@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. Jean-Paul