Changes by Brett Cannon br...@python.org:
--
nosy: -brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
___
___
Python-bugs-list
Aleksi Torhamo alexerion+pythonb...@gmail.com 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,
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
@Aleksy
http://bugs.python.org/issue4501
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
___
Aleksi Torhamo alexerion+pythonb...@gmail.com 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:
Brett Cannon br...@python.org added the comment:
On Tue, Mar 31, 2009 at 06:39, Aleksi Torhamo rep...@bugs.python.orgwrote:
Aleksi Torhamo
alexerion+pythonb...@gmail.comalexerion%2bpythonb...@gmail.com
added the comment:
Sorry for the noise.
I just registered, and started going through
Josiah Carlson josiahcarl...@users.sourceforge.net 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
Aleksi Torhamo alexerion+pythonb...@gmail.com 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
Josiah Carlson josiahcarl...@users.sourceforge.net 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
Changes by Josiah Carlson josiahcarl...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13516/async_no_warn.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
___
Aleksi Torhamo alexerion+pythonb...@gmail.com 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.
Josiah Carlson josiahcarl...@users.sourceforge.net 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
Giampaolo Rodola' billiej...@users.sourceforge.net 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):
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
...after all no read/write methods should be called after the socket has
been closed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
If you're talking about r70904 then you did a different thing than the
one I suggested.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
Tony Meyer anadelonb...@users.sourceforge.net 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
Gregory P. Smith g...@krypto.org added the comment:
A documentation patch would be appreciated, thanks!
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
___
Daniel Diniz aja...@gmail.com 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 rep...@bugs.python.org
Josiah Carlson josiahcarl...@users.sourceforge.net 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
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +brett.cannon
type: - behavior
versions: +Python 2.6 -Python 2.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1161031
___
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
nosy: +giampaolo.rodola
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1161031
___
___
Changes by A.M. Kuchling:
--
assignee: akuchling - josiahcarlson
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1161031
_
___
Python-bugs-list mailing list
21 matches
Mail list logo
