[issue454307] select.select locks up IDE

Change by admin : -- github: None -> 35028 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue423472] Hang in select.select() and time.sleep()

Change by admin : -- github: None -> 34497 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210667] select module: Bug in select.select() (PR#365)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210667] select module: Bug in select.select() (PR#365)

Change by admin : -- github: None -> 32737 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37535] Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1

Wator Sead added the comment: So, that means there are some additional optional operations after do_handshake(), the data is needed. Thanks for explanation! -- ___ Python tracker

[issue37535] Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1

Christian Heimes added the comment: do_handshake() performs just the handshake. TLS protocol can send or receive additional protocol data after the handshake, e.g. alerts, rekeying or renegotiation. The example just happened to not trigger these in TLS 1.2. TLS makes non-blocking IO more

[issue37535] Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1

Wator Sead added the comment: Thanks for explanation, I understand what the reason is. But why do_handshake() not clear of useless data buffer after it is completed? I think that must be easy to do. -- ___ Python tracker

[issue37535] Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1

Christian Heimes added the comment: The problem is caused by the way how TLS 1.3 works. Select considers a TLS 1.3 socket as readable after the handshake, because there is still data on the line. The server is sending session tickets (usually two) after the handshake has been performed. If

[issue37535] Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1

Wator Sead added the comment: All new releases which include an OpenSSL version above 1.1.1 has the same issue. Can anybody fix it? Thanks a lot! -- nosy: +seahoh versions: +Python 3.5, Python 3.8, Python 3.9 ___ Python tracker

[issue37535] Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1

New submission from Dean : Hi, I've come across an issue with OpenSSL 1.1.1, when a client socket wrapped using ssl.wrap_socket() is used in select.select() its always returning ready for reading even though there appears to be nothing to read. To reproduce: 0. Extract files from attached

[issue34934] Consider making Windows select.select interruptible using WSAEventSelect & WSAWaitForMultipleEvents

Change by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34934] Consider making Windows select.select interruptible using WSAEventSelect & WSAWaitForMultipleEvents

Change by ondrej.kutal : -- components: +Extension Modules -Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34934] Consider making Windows select.select interruptible using WSAEventSelect & WSAWaitForMultipleEvents

Change by ondrej.kutal : -- title: Consider making Windows select.select interruptable using WSAEventSelect & WSAWaitForMultipleEvents -> Consider making Windows select.select interruptible using WSAEventSelect & WSAWaitForMul

[issue34934] Consider making Windows select.select interruptable using WSAEventSelect & WSAWaitForMultipleEvents

New submission from Ondra Kutal : At the moment, socket select.select() function is not interruptable on Windows OS (in main thread). Following code cannot be interrupted (for example by CTRL+C): import select, socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setblocking(False

[issue7674] select.select() corner cases: duplicate fds, out-of-range fds

Change by Berker Peksag : -- nosy: +berker.peksag ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

STINNER Victor added the comment: > I recommend to use selectors.PollSelector and fallback on > selectors.SelectSelector where not available (Windows) in order to use 1 > syscall only. That's what we did already in socket.py, subprocess.py and > others. It would be

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

Giampaolo Rodola' added the comment: I recommend to use selectors.PollSelector and fallback on selectors.SelectSelector where not available (Windows) in order to use 1 syscall only. That's what we did already in socket.py, subprocess.py and others. -- nosy:

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

STINNER Victor added the comment: > Better alternative will be to use poll or epoll even. epoll requires mulitple system calls, whereas the selector seems to only be used only once in most cases, no? Anyway, maybe selectors.DefaultSelector can be used here? About

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

0979/what-are-the-differences-between-poll-and-select#3951845. Better alternative will be to use poll or epoll even. -- components: Library (Lib) messages: 303127 nosy: Беатрис Бонева priority: normal severity: normal status: open title: Use select.poll instead of sele

[issue30847] asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select()

STINNER Victor added the comment: Ok, it makes sense. Thanks :-) -- ___ Python tracker ___ ___

[issue30847] asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select()

Pim Klanke added the comment: > "Let's say that we got read event on sockets A and B (in an ordered list from > selectors: A, then B), but B gets urgent data: should we handle B urgent data > before not-urgent A data?" IMO No. The same strategy applies. urgent data events on B have priority

[issue30847] asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select()

Pim Klanke added the comment: This is in fact the third catagory of select(), "exceptional conditions", but because some find the term "exceptional" confusing when used in a Python module, we decided to use the term "urgent data", borrowed from the poll(2) man page. (see bpo-30844) An

[issue30847] asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select()

Guido van Rossum added the comment: How do you define "urgent data"? Is this just the third category of select(), Read, Write, Exceptional? I don't know if that should be considered urgent, it's just "out of band" IIRC. -- ___ Python tracker

[issue30847] asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select()

STINNER Victor added the comment: In the selectors issue, we discussed how an application should prioritize "urgent" events: http://bugs.python.org/issue30844#msg297707 While I now agree that it's not the role of selectors to decide, I would like to discuss the plan for asyncio. Let's say

[issue30847] asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select()

Changes by Pim Klanke <p...@protonic.nl>: -- title: asyncio: selector_events: add_excepter(), 3rd argument of select.select() -> asyncio: selector_events: add_urgent() for urgent data to read, 3rd argument of select.select() ___ Python tra

[issue30847] asyncio: selector_events: add_excepter(), 3rd argument of select.select()

Pim Klanke added the comment: To be able to use GPIO Sysfs Interface with asyncio on our embedded platforms, we require exceptional event support in asyncio. depends on bpo-30844 -- ___ Python tracker

[issue30847] asyncio: selector_events: add_excepter(), 3rd argument of select.select()

STINNER Victor added the comment: Does the Windows Proactor event loop has a similar concept of "excepter"? -- ___ Python tracker ___

[issue30847] asyncio: selector_events: add_excepter(), 3rd argument of select.select()

STINNER Victor added the comment: Please elaborate the description :-) -- nosy: +haypo ___ Python tracker ___

[issue30847] asyncio: selector_events: add_excepter(), 3rd argument of select.select()

New submission from Pim Klanke: depends on bpo-30844 -- components: asyncio messages: 297652 nosy: pklanke, yselivanov priority: normal severity: normal status: open title: asyncio: selector_events: add_excepter(), 3rd argument of select.select() type: enhancement versions: Python 3.7

[issue30844] selectors: add_excepter(), 3rd argument of select.select()

Changes by Pim Klanke <p...@protonic.nl>: -- components: -asyncio title: selectors and asyncio: add_excepter(), 3rd argument of select.select() -> selectors: add_excepter(), 3rd argument of select.select() ___ Python tracker <rep...@bug

[issue30844] selectors and asyncio: add_excepter(), 3rd argument of select.select()

Changes by STINNER Victor <victor.stin...@gmail.com>: -- title: selector_events.py lacks exceptional event support -> selectors and asyncio: add_excepter(), 3rd argument of select.select() versions: -Python 3.4, Python 3.5, Python 3.6 _

[issue27634] selectors.SelectSelectors fails if select.select was patched

Brett Cannon added the comment: Thanks for the patch, Przemyslaw, but I'm going to close this. -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue27634] selectors.SelectSelectors fails if select.select was patched

Brett Cannon added the comment: I agree with Victor: monkeypatching is the wrong way to deal with this. Since SelectSelector is a class you are better off exposing something in the constructor or some method that can be overridden if this kind of flexibility is really necessary. --

[issue27634] selectors.SelectSelectors fails if select.select was patched

STINNER Victor added the comment: Monkey-patching is a bad programming practice. I don't think that Python should promote this... *But* selectors.diff LGTM. I will wait one or two weeks to let others review the patch and give their opinion. -- nosy: +haypo

[issue27634] selectors.SelectSelectors fails if select.select was patched

Przemyslaw Wegrzyn added the comment: Possible workaround in the patch attached. -- keywords: +patch Added file: http://bugs.python.org/file43910/selectors.diff ___ Python tracker

[issue27634] selectors.SelectSelectors fails if select.select was patched

New submission from Przemyslaw Wegrzyn: The SelectSelector makes a local copy of select.select() built-in and calls it via self._select later on. It no longer works if select.select() built-in is replaced with function (something gevent's monkey patching does). Currently gevent employs

[issue25371] select.select docstring needs comma

Roundup Robot added the comment: New changeset 99c82576bb70 by Benjamin Peterson in branch '3.4': add a missing comma (closes #25371) https://hg.python.org/cpython/rev/99c82576bb70 New changeset ae98209ff69a by Benjamin Peterson in branch '3.5': merge 3.4 (#25371)

[issue25371] select.select docstring needs comma

New submission from Chris Angelico: The grammar of the IMPORTANT NOTICE on the select module and the select.select function wants a comma, I think. Patch attached. -- assignee: docs@python components: Documentation files: add_comma.patch keywords: patch messages: 252750 nosy: Rosuav

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___ ___ Python-bugs-list mailing list

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

Roundup Robot added the comment: New changeset 180e4b678003 by Victor Stinner in branch 'default': Issue #20320: select.select() and select.kqueue.control() now round the timeout http://hg.python.org/cpython/rev/180e4b678003 -- nosy: +python-dev

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: Can I commit time_rouding-3.patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___ ___

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: According to my last tests, we should still round select and kqueue timeout away from zero. http://bugs.python.org/issue20505#msg210908 -- resolution: invalid - status: closed - open ___ Python tracker

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

a real impact. Can someone please review my new patch? I now think that select.select() should also be fixed in Python 3.4 to be consistent with the new select.poll() and select.epoll.poll() behaviour (timeout rounding). See msg210914 and msg210915 ( http://bugs.python.org/issue20505#msg210914

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

Charles-François Natali added the comment: STINNER Victor added the comment: Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)... After many many tests with asyncio (last

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: Now, rounding away from zero for select/kqueue is fine to me, just to be consistent. Did you take a look at time_rouding-2.patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: Antoine asks me on Rietveld why I chose to round up in signal.sigtimedwait(). I consider that sigtimedwait() is similar to select and kqueue: it's a function to wait for an event with a timeout. IMO it should use the same rounding method. Don't you think so?

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

Antoine Pitrou added the comment: I consider that sigtimedwait() is similar to select and kqueue: it's a function to wait for an event with a timeout. IMO it should use the same rounding method. Don't you think so? I don't really care how sigtimedwait() rounds its timeout, I just tried to

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: But originally this issue only affects event loops, so presumably it'd be reasonable to stick to select()-alikes. Ok, here is a new patch which doesn't change signal.sigtimedwait() (still round down, towards zero). -- Added file:

[issue7674] select.select() corner cases: duplicate fds, out-of-range fds

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: -BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7674 ___ ___

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: I reverted my changes on poll and epoll: the kernel may round the timeout differently because it uses a different clock, so Python cannot guarantee that it will wait at least timeout seconds. My initial concern was a performance issue in asyncio, I fixed the

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

STINNER Victor added the comment: Timings on my laptop: import time, select t0=time.perf_counter(); select.select([], [], [], 1e-6); dt=time.perf_counter()-t0; dt ([], [], []) 0.00012494399561546743 t0=time.perf_counter(); select.select([], [], [], 0); dt=time.perf_counter()-t0; dt

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

(), datetime.datetime.utcfromtimestamp() - select.select(), _PyTime_ObjectToTimespec() is used in various places: - posix.utime() - signal.sigtimedwait() - select.kqueue.control() - time.clock_settime() Attached patch adds a new round parameter to _PyTime_ObjectToTimeval() and _PyTime_ObjectToTimespec() to choose

[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound

Charles-François Natali added the comment: Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)... -- ___ Python tracker

[issue15032] Provide a select.select implemented using select.poll

Éric Araujo added the comment: This may be obsoleted by the new selectors module. -- nosy: +eric.araujo, neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15032 ___

[issue15032] Provide a select.select implemented using select.poll

Changes by Gregory P. Smith g...@krypto.org: -- resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15032 ___

select.select()

please help me.. what does the following line do? read_sockets,write_sockets,error_sockets = select.select(CONNECTION_LIST,[],[]) -- https://mail.python.org/mailman/listinfo/python-list

Re: select.select()

In article b8d42424-e0ab-4595-9c87-25e5c1b53...@googlegroups.com, Bhanu Karthik bhanukarthik2...@gmail.com wrote: please help me.. what does the following line do? read_sockets,write_sockets,error_sockets = select.select(CONNECTION_LIST,[],[]) This is a little tricky. First,read the docs

Re: select.select()

On Fri, 22 Nov 2013 17:42:07 -0800, Bhanu Karthik wrote: please help me.. what does the following line do? read_sockets,write_sockets,error_sockets = select.select(CONNECTION_LIST,[],[]) The select.select function takes three arguments (plus an optional fourth): select.select(read_list

Re: select.select()

On Friday, 22 November 2013 18:29:12 UTC-8, Steven D'Aprano wrote: On Fri, 22 Nov 2013 17:42:07 -0800, Bhanu Karthik wrote: please help me.. what does the following line do? read_sockets,write_sockets,error_sockets = select.select(CONNECTION_LIST

Re: select.select()

= select.select(CONNECTION_LIST,[],[]) This is a little tricky. First,read the docs at http://docs.python.org/2/library/select.html. There's a lot of complicated stuff there, but just concentrate on the description of the select.select() call for now. Imagine a process

Re: select.select()

On Sat, Nov 23, 2013 at 1:15 PM, Roy Smith r...@panix.com wrote: (*) I'm not sure if real MUDs are programmed this way, but it's a plausible architecture. For simplicity sake, I'm assuming a single-threaded server. Yeah, they certainly can. That's effectively the way that I programmed the MUD

[issue7674] select.select() corner cases: duplicate fds, out-of-range fds

Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7674 ___ ___ Python-bugs-list

[issue16230] select.select crashes on resized lists

Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16230 ___ ___

[issue16230] select.select crashes on resized lists

Roundup Robot added the comment: New changeset 87ccf2635ad7 by Antoine Pitrou in branch '3.2': Issue #16230: Fix a crash in select.select() when one the lists changes size while iterated on. http://hg.python.org/cpython/rev/87ccf2635ad7 New changeset 717660ec8f67 by Antoine Pitrou in branch

[issue16230] select.select crashes on resized lists

Antoine Pitrou added the comment: Committed, thank you! -- nosy: +pitrou resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16230

[issue16230] select.select crashes on resized lists

Changes by Serhiy Storchaka storch...@gmail.com: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16230 ___ ___

[issue16230] select.select crashes on resized lists

Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16230 ___ ___

[issue15032] Provide a select.select implemented using select.poll

Giampaolo Rodola' added the comment: It's not clear to me how you intend to provide this exactly. To me it looks like a good candidate for a recipe, otherwise I don't see it as a good fit for the stdlib. -- nosy: +giampaolo.rodola ___ Python

[issue15032] Provide a select.select implemented using select.poll

Gregory P. Smith added the comment: indeed, i don't know that there is any point to this idea. i'm all for just getting rid of all uses of select in the stdlib and making them poll only in 3.4 unless someone can point to a modern system that does not support poll. --

[issue16230] select.select crashes on resized lists

New submission from Serhiy Storchaka: Simple crash code: import select a = [] class F: def fileno(self): del a[-1] return 1 a[:] = [F()] * 10 select.select([], a, []) -- components: Extension Modules messages: 172871 nosy: serhiy.storchaka priority: normal severity

[issue16230] select.select crashes on resized lists

Serhiy Storchaka added the comment: Here is a patch. -- keywords: +patch Added file: http://bugs.python.org/file27564/select_resized_list.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16230

[issue16230] select.select crashes on resized lists

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16230 ___ ___ Python-bugs-list mailing list

[issue15032] Provide a select.select implemented using select.poll

New submission from Gregory P. Smith g...@krypto.org: Many random bits of the standard library were originally written using select.select. This is an ancient API that is available everywhere, but these days you'd be hard pressed to find _any_ system that does not implement the superior poll

[issue15032] Provide a select.select implemented using select.poll

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15032 ___ ___ Python-bugs-list mailing list

[issue11459] Python select.select does not correctly report read readyness

Ross Lagerwall rosslagerw...@gmail.com added the comment: Attached is a patch which uses -1 for the buffer size of popen(). This gets translated by the io.open() to the default io buffer size. -- Added file: http://bugs.python.org/file21290/11459_v2.patch

[issue11459] Python select.select does not correctly report read readyness

Antoine Pitrou pit...@free.fr added the comment: Here is the adapted patch for 3.1, with a test case. -- nosy: +pitrou Added file: http://bugs.python.org/file21291/11459_v3.patch ___ Python tracker rep...@bugs.python.org

[issue11459] Python select.select does not correctly report read readyness

Roundup Robot devnull@devnull added the comment: New changeset 1dc52ecb8949 by Antoine Pitrou in branch '3.1': Issue #11459: A `bufsize` value of 0 in subprocess.Popen() really creates http://hg.python.org/cpython/rev/1dc52ecb8949 New changeset 7451da272111 by Antoine Pitrou in branch '3.2':

[issue11459] Python select.select does not correctly report read readyness

Antoine Pitrou pit...@free.fr added the comment: Fixed now, thank you! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org

[issue11459] Python select.select does not correctly report read readyness

Gregory P. Smith g...@krypto.org added the comment: yeah i figured importing io from os at the top level might be a problem. it is not important for the default to be that exact value, even something safely on the small side like 512 will work. but we could just have the default be set in

[issue11459] Python select.select does not correctly report read readyness

Gregory P. Smith g...@krypto.org added the comment: ross's patch looks good to me. Isn't the behavior just plain broken in 3.1 and 3.2? The docs say that the default bufsize=0 is unbuffered in Popen but the implementation has that nasty XXX to make it line buffered instead of unbuffered in

[issue11459] Python select.select does not correctly report read readyness

Gregory P. Smith g...@krypto.org added the comment: to get that behavior, change the =1 default to =io.DEFAULT_BUFFER_SIZE in ross's patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11459

[issue11459] Python select.select does not correctly report read readyness

Ross Lagerwall rosslagerw...@gmail.com added the comment: to get that behavior, change the =1 default to =io.DEFAULT_BUFFER_SIZE in ross's patch. The problem is, it doesn't seem like you can import and use io.DEFAULT_BUFFER_SIZE from inside os.py. Python fails to start. You can import

[issue11459] Python select.select does not correctly report read readyness

Novimir Pablant amici...@gmail.com added the comment: I agree with Gregory that fixing this in 3.1 and 3.2 is the way to go. Otherwise I would suggest changing the documentation to match the behavior. -- ___ Python tracker rep...@bugs.python.org

[issue11459] Python select.select does not correctly report read readyness

Ross Lagerwall rosslagerw...@gmail.com added the comment: The Charles' patch fixes the problem but breaks [test_os test_poll test_popen test_select test_uuid] when running make test. Those two lines were introduced by Guido in [1f7891d84d93] but that was back in 2007 when subprocess used

[issue11459] Python select.select does not correctly report read readyness

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11459 ___ ___ Python-bugs-list

[issue11459] Python select.select does not correctly report read readyness

Charles-Francois Natali neolo...@free.fr added the comment: Could you try with the attached patch ? The problem is that subprocess silently replaces bufsize=0, so child.stdout is actually buffered, and when you read just one byte, everything that's available for reading is read into the

[issue11459] Python select.select does not correctly report read readyness

Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11459 ___ ___

[issue11459] Python select.select does not correctly report read readyness

Changes by Ross Lagerwall rosslagerw...@gmail.com: -- nosy: +rosslagerwall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11459 ___ ___

[issue11459] Python select.select does not correctly report read readyness

Novimir Pablant amici...@gmail.com added the comment: Applying the patch appears to fix this problem. Thanks! I am definitely confused about why the buffer was changed to line buffered in the first place, especially since the default is bufsize=0 and the comment (# Nearly unbuffered (XXX for

[issue11459] Python select.select does not correctly report read readyness

New submission from Novimir Pablant amici...@gmail.com: I am trying to get the output from an external program into python using `subprocess.Popen` and `select.select`. For some reason though select.select is at times telling me that stdout is not ready to read, even when it is (reading

[issue11459] Python select.select does not correctly report read readyness

Novimir Pablant amici...@gmail.com added the comment: I forgot to mention, I am running on OS X 10.6.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11459 ___

[issue7674] select.select() corner cases: duplicate fds, out-of-range fds

Mark Lawrence breamore...@yahoo.co.uk added the comment: Chris, to me it's as clear as mud but please produce a doc patch anyway. :) -- assignee: georg.brandl - d...@python nosy: +BreamoreBoy, d...@python ___ Python tracker rep...@bugs.python.org

[issue7674] select.select() corner cases: duplicate fds, out-of-range fds

Changes by Antoine Pitrou pit...@free.fr: -- assignee: d...@python - components: -Documentation nosy: +exarkun versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7674 ___

Re: Windows - select.select, timeout and KeyboardInterrupt

In message mailman.2769.1273327083.23598.python-l...@python.org, exar...@twistedmatrix.com wrote: On 07:48 am, l...@geek-central.gen.new_zealand wrote: In message mailman.2760.1273288730.23598.python-l...@python.org, exar...@twistedmatrix.com wrote: This is a good example of why it's a bad

Re: Windows - select.select, timeout and KeyboardInterrupt

Am 09.05.2010 11:59, schrieb Lawrence D'Oliveiro: In messagemailman.2769.1273327083.23598.python-l...@python.org, exar...@twistedmatrix.com wrote: On 07:48 am, l...@geek-central.gen.new_zealand wrote: In messagemailman.2760.1273288730.23598.python-l...@python.org, exar...@twistedmatrix.com

Re: Windows - select.select, timeout and KeyboardInterrupt

In message mailman.2760.1273288730.23598.python-l...@python.org, exar...@twistedmatrix.com wrote: This is a good example of why it's a bad idea to use select on Windows. Instead, use WaitForMultipleObjects. How are you supposed to write portable code, then? --

Re: Windows - select.select, timeout and KeyboardInterrupt

this: ... select.select(r, w, e, timeout) scheduler() # checks for scheduled calls to be fired ... ...imagine a case where there's a connection (aka a dispatcher instance) which does not receive or send any data *and* a scheduled call which is supposed to be fired after, say, 5

Re: Windows - select.select, timeout and KeyboardInterrupt

On Sat, 8 May 2010 13:47:53 +0200 Giampaolo Rodolà g.rod...@gmail.com wrote: Assuming loop() function does something like this: ... select.select(r, w, e, timeout) scheduler() # checks for scheduled calls to be fired ... ...imagine a case where there's a connection

Re: Windows - select.select, timeout and KeyboardInterrupt

On 07:48 am, l...@geek-central.gen.new_zealand wrote: In message mailman.2760.1273288730.23598.python-l...@python.org, exar...@twistedmatrix.com wrote: This is a good example of why it's a bad idea to use select on Windows. Instead, use WaitForMultipleObjects. How are you supposed to write

  1   2   >