[issue909005] asyncore fixes and improvements

Giampaolo Rodola' added the comment: I agree with Josiah but I must say that the handle_close() documentation is a bit misleading. Currently it states: > handle_close() >Called when the socket is closed. I'd change it with something like this: "Called when the asynchronous loop detects t

[issue909005] asyncore fixes and improvements

Josiah Carlson added the comment: Just to make this clear, Aleksi is proposing close() should be called automatically by some higher-level functionality whether a user has overridden handle_close() or not. With the updated asyncore warning suppression stuff, overriding handle_close() for the

[issue909005] asyncore fixes and improvements

Aleksi Torhamo added the comment: > It's already done automatically if you don't override handle_close. Sorry, i meant the case where you need to override it. If we always need to call close() from handle_close(), it feels redundant having to remember to add it, when it could be done automatica

[issue909005] asyncore fixes and improvements

Giampaolo Rodola' added the comment: > I can't think of a situation where handle_close() is called, but close() > should not be called. If indeed so, i feel it's weird to require the > user remember to call close(), and it should IMHO be done automatically. It's already done automatically if yo

[issue909005] asyncore fixes and improvements

Aleksi Torhamo added the comment: I just remembered that "level 1" function handle_connect_event() is also called from "level 2", so i actually can't see why the close helper could not be called handle_close_event(). Is there some other reason besides "breaking abstraction" to not introduce it?

[issue909005] asyncore fixes and improvements

Aleksi Torhamo added the comment: "not the handle_close_event() replacements, stick with handle_close()". I'm guessing this has to do with "breaking the abstraction"? I can't think of a situation where handle_close() is called, but close() should not be called. If indeed so, i feel it's weird t

[issue909005] asyncore fixes and improvements

Josiah Carlson <[EMAIL PROTECTED]> added the comment: I have applied my variant patch to trunk, which will be in 3.0 this weekend. -- resolution: -> out of date status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue909005] asyncore fixes and improvements

Bill Janssen added the comment: I should point out that I'm doing a big project with SSL and Python, using Medusa, and asyncore. I've been re-working the 2.6 and 3.x SSL support (with guidance from Giampolo :-) so that true async capability is possible for SSL. -- nosy: +janssen __

[issue909005] asyncore fixes and improvements

Changes by Giampaolo Rodola': -- nosy: +giampaolo.rodola Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Unsubscribe: