hey > One thing I would like to raise is the issue of KeyboardInterrupt. I find > very inconvenient that a normal application doing a very simple blocking > read from a socket can't be interrupted by a CTRL+C sequence. Usually, what > I do is to setup a timeout on the sockets (eg. 0.4 seconds) and then simply > retry if the data has not arrived yet. But this changes the code from:
from my experience with linux and solaris, this CTRL+C problem only happens on windows machines. but then again, windows can't select() on anything but sockets, so there's not gonna be a generic solution. setting timeouts has some issues (inefficiency, platform dependency, etc.). but it's a good point to take into account. i'll see where that fits. -tomer On 6/5/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > tomer filiba wrote: > > > some time ago i wrote this huge post about stackable IO and the > > need for a new socket module. i've made some progress with > > those, and i'd like to receive feedback. > > > > * a working alpha version of the new socket module (sock2) is > > available for testing and tweaking with at > > http://sebulba.wikispaces.com/project+sock2 > > > > * i'm working on a version of iostack... but i don't expect to make > > a public release until mid july. in the meanwhile, i started a wiki > > page on my site for it (motivation, plans, design): > > http://sebulba.wikispaces.com/project+iostack > > with lots of pretty-formatted info. i remember people saying > > that stating `read(n)` returns exactly `n` bytes is problematic, > > can you elaborate? > > Hi Tomer, this is great stuff you're doing! It's something that's really > needed in my opinion. Basically, right now there's only a convention of > passing around duck-typed things which have a "read" method, and that's all! > It's nice to better define this duck-typed interface, and it seems you're > doing very good progress on that. I hope I have more time to properly > comment on this later (I'll wait for the first iteration of comments). > > One thing I would like to raise is the issue of KeyboardInterrupt. I find > very inconvenient that a normal application doing a very simple blocking > read from a socket can't be interrupted by a CTRL+C sequence. Usually, what > I do is to setup a timeout on the sockets (eg. 0.4 seconds) and then simply > retry if the data has not arrived yet. But this changes the code from: > > data = sock.recv(10) > > to: > > while 1: > try: > data = sock.recv(10) > except socket.timeout: > # just so that CTRL+C is processed > continue > else: > break > > which is IMO counter-intuitive and un-pythonic. It's such a convoluted code > that it happened once to me that another programmer collapsed this back into > the bare sock.recv() because he couldn't immediately see why that complexity > was required (of course, comments might have helped and stuff, but I guess > you see my point). > > I believe that this kind of things ought to work by default with the minimum > possible amount of code. Specifically, I think that the new iostack should > allow blocking mode without trapping CTRL+C by default (which is the normal > behaviour expected). I'm not sure if it's worth doing the auto-retry trick > internally (bleah), or implement blocking calls with a call to select() so > that you can also wait on signals, or something like that; I don't have a > suggestion at this point, but I thought it was worth to raise the issue. > -- > Giovanni Bajo > > _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
