[Python-3000] iostack and sock2

[Giovanni Bajo]

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