Changes by Martin v. Löwis mar...@v.loewis.de:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
___
Barry A. Warsaw ba...@python.org added the comment:
Just to close the loop: thanks for reverting this for 2.6.6!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
Barry A. Warsaw ba...@python.org added the comment:
The fix for this was applied after 2.6.6rc1, and it wasn't approved by me. Is
it critical for 2.6? Is it a regression since 2.6.5? The way I see it, we
either back this out or release an rc2. There may be other reasons to release
an rc2,
Changes by Barry A. Warsaw ba...@python.org:
--
priority: normal - release blocker
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
Martin v. Löwis mar...@v.loewis.de added the comment:
What date would the final release then be made? It would be best if it could be
done before Aug 27. If necessary, I could also make a release on September 6
(but not any day before or after)
--
Martin v. Löwis mar...@v.loewis.de added the comment:
The bug is not a regression since 2.6.5; AFAICT, it was in Python forever. I
recommend to revert the checkin, and postpone fixing it to 2.7.1.
--
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw ba...@python.org added the comment:
I agree w/mvl. Giampaolo, please revert this for 2.6.6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
Giampaolo Rodola' g.rod...@gmail.com added the comment:
The commit was made on August 04, 11:05 AM, while rc1 was released at 06:09 PM.
I don't think the patch is going to introduce any problem but if you think it's
the case to revert it then I'll do it.
--
R. David Murray rdmur...@bitdance.com added the comment:
The question isn't when it was released, but when it was tagged, and that
happened at Aug 3 22:51:57 2010 UTC according to svn. Your commit was made Aug
4 08:58:38 2010 UTC.
--
nosy: +r.david.murray
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Ok, no problem. Reverted in r83969.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Fixed in r83703 (2.7), r83704 (2.6), r83705 (3.2) and r83706 (3.1).
Thanks for the patch.
--
resolution: - fixed
status: open - closed
versions: +Python 2.6, Python 3.1, Python 3.2
___
Python
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 2.7 -Python 2.5, Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Assigning this to me. The patch looks correct, it only needs tests assuming it
is possible to write a reliable test for this.
--
assignee: - giampaolo.rodola
___
Python tracker
Changes by intgr ma...@juffo.org:
--
nosy: +intgr
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
___
Python-bugs-list mailing list
Changes by Forest Wilkinson for...@users.sourceforge.net:
--
nosy: +forest
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2944
___
___
Alexander Shigin [EMAIL PROTECTED] added the comment:
I've got the same error in r64768.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2944
___
___
Alexander Shigin [EMAIL PROTECTED] added the comment:
Here is a new patch against r64768
The new patch raise an exception if asynchronous connect fails.
Added file: http://bugs.python.org/file10856/asyncore-connect-patch.diff
___
Python tracker [EMAIL
Changes by Alexander Shigin [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10401/asyncore-connect-patch.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2944
___
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
nosy: +giampaolo.rodola, josiah.carlson, josiahcarlson
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2944
__
___
Giampaolo Rodola' [EMAIL PROTECTED] added the comment:
By trying your script on Linux and Windows I notice different behaviors.
On Windows handle_expt is always called.
On Linux, no matter if using select or poll, handle_accept is called,
then an exception is thrown at the time the data is going
Alexander Shigin [EMAIL PROTECTED] added the comment:
Oh, fine. May be handle_error should have been called, but anyway not
handle_connect.
But in my mind, handle_expt is better.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2944
Alexander Shigin [EMAIL PROTECTED] added the comment:
Patch against r63534 fix the issue.
--
keywords: +patch
Added file: http://bugs.python.org/file10401/asyncore-connect-patch.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2944
New submission from Alexander Shigin [EMAIL PROTECTED]:
Unix select returns socket in read fd set and write fd set if
nonblocking socket attempts to connect to unaviable address.
asyncore should check this case by calling getsockopt with SO_ERROR
optname. If return value is 0 it should call
Alexander Shigin [EMAIL PROTECTED] added the comment:
Oh, I've just realised that FreeBSD is too fast. test_async_connect.py
works fine on linux box, but on FreeBSD i need to change localhost to
another host :(
I haven't got any idea how to make a test case which work on any
machine.
24 matches
Mail list logo
