On Wed, Mar 4, 2009 at 1:31 PM, Guido van Rossum <gu...@python.org> wrote: > On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough <chr...@plope.com> wrote: >> Daniel Stutzbach wrote: >>> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum <gu...@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 _______________________________________________ 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
