[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Josiah Carlson]

On Wed, Mar 4, 2009 at 1:31 PM, Guido van Rossum <guido at python.org> wrote:
> On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough <chrism at plope.com> wrote:
>> Daniel Stutzbach wrote:
>>> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum <guido at python.org> wrote:
>>>
>>>> The same as always. We don't change APIs in bugfix releases.
>>>>
>>>
>>> This question is actually for the Zope folks and others who have had
>>> problems with the 2.6 asyncore/asynchat:
>>>
>>> Are any of the problems due to a change in the documented API... or are they
>>> all due to changes in undocumented internals that your code relied on?
>>
>> As far as I can tell, asyncore/asynchat is all "undocumented internals".  Any
>> use of asyncore in anger will use internals; there never was any well-understood
>> API to these modules.  Medusa itself (from which asyncore and asynchat were
>> derived) appears to itself break with the changes to asyncore/asynchat in 2.6
>> (at least it appears to use attributes like "ac_out_buffer" which were removed
>> in 2.6; this is not "Zope's version"; there is no such animal; this is plain old
>> Medusa 0.5.4).
>>
>> Count me in as one who believes that it would be the lesser of two evils to
>> revert to the older (2.5 and prior) asyncore/asynchat implementations in 2.6.2
>> rather than soldiering on with the 2.6 and 2.6.1 implementation (which almost
>> certainly has fewer, if any, consumers); somebody messed up in 2.6 by making its
>> asyncore/asynchat more forward compatible with 3.0's than backwards compatible
>> with 2.5's and prior; this was just a mistake and keeping old code running
>> should trump any theoretical or puritanical benefit in a dot release.
>
> Then I'd like to hear from the folks who made and reviewed those
> changes to asyncore in 2.6. I can't imagine the changes were done
> without good intentions.

Interestingly enough, I just accidentally found this thread with an
unrelated web search, but it makes sense to reply.

Why the changes to asyncore:
1) the internals of asyncore were inefficient
2) the API and general behavior of the handle_*(), readable() and
writable() methods are unchanged, which are *exactly* what a user
should be overriding with subclassing
3) anyone modifying the *internals* of the implementation for the sake
of speed, shouldn't need to anymore

Maybe I have misread the posts in this thread, but does anyone have
any examples of their code breaking when only overriding handle_*(),
readable(), and writable() methods?

 - Josiah