[issue1161031] Neverending warnings from asyncore

Changes by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1161031] Neverending warnings from asyncore

Giampaolo Rodola' added the comment: If you're talking about r70904 then you did a different thing than the one I suggested. -- ___ Python tracker ___

[issue1161031] Neverending warnings from asyncore

Josiah Carlson added the comment: Good point Giampaolo. Fixed and committed. -- ___ Python tracker ___ ___ Python-bugs-list mailin

[issue1161031] Neverending warnings from asyncore

Giampaolo Rodola' added the comment: ...after all no read/write methods should be called after the socket has been closed. -- ___ Python tracker ___ __

[issue1161031] Neverending warnings from asyncore

Giampaolo Rodola' added the comment: I still get some occasional EBADF failures when running pyftpdlib test suite by using poll(). I think that it makes more sense moving the: if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL): obj.handle_close() ...lines at the

[issue1161031] Neverending warnings from asyncore

Josiah Carlson added the comment: Fixed the close() call and committed to trunk. Python 2.6 tests pass with the new version of the library. Calling it good :) . -- keywords: -needs review resolution: -> accepted status: open -> closed ___ Python

[issue1161031] Neverending warnings from asyncore

Aleksi Torhamo added the comment: Ah, you're right. I hadn't thought about the exceptional condition being used to signal anything besides OOB. Looks really good to me. s/close/_exception/ in the select-based poll(), and i don't have anything more to add. -- _

[issue1161031] Neverending warnings from asyncore

Changes by Josiah Carlson : Removed file: http://bugs.python.org/file13516/async_no_warn.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue1161031] Neverending warnings from asyncore

Josiah Carlson added the comment: You are right. Handling OOB data is within the "exceptional condition" that the select document specifies. I've added a check for error conditions within handle_expt_event(), which induces a handle_close() on discovery of an error, handle_expt() otherwise.

[issue1161031] Neverending warnings from asyncore

Aleksi Torhamo added the comment: The _exception() -> close() change seems to be wrong. The third set of select() is supposed to represent oob data, so the previous use in the select-based loop should have been correct? Other than that, i can't see anything wrong with it. Maybe handle_expt_eve

[issue1161031] Neverending warnings from asyncore

Josiah Carlson added the comment: Your analysis WRT handle_expt_event() is correct. I've been meaning to fix that for a while, but I forgot to do it in 2.6/3.0 with all of the other changes/fixes. Looking at the docs, you are also right about POLLNVAL. I also don't *know* what to do when p

[issue1161031] Neverending warnings from asyncore

Brett Cannon added the comment: On Tue, Mar 31, 2009 at 06:39, Aleksi Torhamo wrote: > > Aleksi Torhamo > > > added the comment: > > Sorry for the noise. > > I just registered, and started going through the open issues for > asyncore in order. I'll read them all through before commenting on th

[issue1161031] Neverending warnings from asyncore

Aleksi Torhamo added the comment: Sorry for the noise. I just registered, and started going through the open issues for asyncore in order. I'll read them all through before commenting on the next one.. I also bumped to this: http://groups.google.com/group/python-dev2/browse_thread/thread/eec1d

[issue1161031] Neverending warnings from asyncore

Giampaolo Rodola' added the comment: @Aleksy http://bugs.python.org/issue4501 -- ___ Python tracker ___ ___ Python-bugs-list mailin

[issue1161031] Neverending warnings from asyncore

Aleksi Torhamo added the comment: Please correct me, if i'm wrong, but this seems to be a real bug, caused by people thinking that handle_expt is something like handle_error. As Tony stated, the docs say that handle_expt is called when out-of-band data arrives, and that is - i think - correct.

[issue1161031] Neverending warnings from asyncore

Gregory P. Smith added the comment: A documentation patch would be appreciated, thanks! -- nosy: +gregory.p.smith ___ Python tracker ___ __

[issue1161031] Neverending warnings from asyncore

Tony Meyer added the comment: None of my arguments have really changed since 2.4. I still believe that this is a poor choice of default behaviour (and if it is meant to be overridden to be useable, then 'pass' or 'raise NotYetImplementedError' would be a better choice). However, my impressi

[issue1161031] Neverending warnings from asyncore

Josiah Carlson added the comment: Considering that we're looking at 2.7 and 3.1, I think that (paraphrased) "logging fallout from changes to 2.4" are a bit out-of- date. People who have continued to use asyncore/asynchat in the last 4 years have already changed their code. People who write

[issue1161031] Neverending warnings from asyncore

Daniel Diniz added the comment: Josiah: that'd be around rev36408, as 1.53 corresponds to rev36033 (from the log and issue 957240) -- nosy: +ajaksu2 stage: -> test needed ___ Python tracker ___

[issue1161031] Neverending warnings from asyncore

Changes by Daniel Diniz : -- nosy: +brett.cannon type: -> behavior versions: +Python 2.6 -Python 2.4 ___ Python tracker ___ ___ Pyt

[issue1161031] Neverending warnings from asyncore

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bu

[issue1161031] Neverending warnings from asyncore

Changes by A.M. Kuchling: -- assignee: akuchling -> josiahcarlson _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list