What Im getting at is that a Python IO model should maybe go a little further than "tradtional" IO - asynchronous IO and synchronisation capabilities should also be specified. Of course, these would be optional, but it would be excellent if a platform could easily slot into pre-defined Python semantics if possible.
What Python could do with reasonable ease is a sort of "promise" model, where an I/O operation returns an object that waits for the I/O to complete upon access or destruction. Something like def foo(): obj = stdin.delayed_read() obj2 = stdout.delayed_write("data") do_lengthy_computation() data = obj.get() # Here we wait for the read to complete del obj2 # Here we wait for the write to complete. This gives a fairly nice programming model. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
[Jack seems to like an asynch IO model]
def foo(): obj = stdin.delayed_read() obj2 = stdout.delayed_write("data") do_lengthy_computation() data = obj.get() # Here we wait for the read to complete del obj2 # Here we wait for the write to complete.
This gives a fairly nice programming model.
Indeed. Taking this a little further, I come up with something like: inlock = threading.Lock() buffer = stdin.delayed_read(inlock) outlock = threading.Lock() stdout.delayed_write(outlock, "The data") fired = threading.Wait(inlock, outlock) # new fn :-) if fired is inlock: # etc. The idea is we can make everything wait on a single lock abstraction. threading.Wait() could accept lock objects, thread objects, Sockets, etc. Obviously a bit to work out, but it does make an appealing model. OTOH, I wonder how it fits with continutations etc. Not too badly from my weak understanding. May be an interesting convergence! Mark.
participants (2)
-
Jack Jansen -
Mark Hammond