[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
josiah.carlson at gmail.com
Thu Mar 5 08:46:18 CET 2009
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?
More information about the Python-Dev