On 6-jun-2006, at 11:51, Nick Coghlan wrote: > Greg Ewing wrote: >> tomer filiba wrote: >> >>> okay, i give up on read(n) returning n bytes. >> >> An idea I had about this some time ago was that read() >> could be callable with two arguments: >> >> f.read(min_bytes, max_bytes) >> >> The two variations we're considering would then be special >> cases of this: >> >> f.read(0, num_bytes) # current read() behaviour >> >> f.read(num_bytes, num_bytes) # record-oriented read() behaviour > > You can even makes this backwards compatible by having the > min_bytes argument > default to 0. (whether or not the order of the two arguments should be > reversed in that case is debatable, though)
I'm slighly worried about this thread. Async I/O and "read exactly N bytes" don't really match up. I don't know about the other mechanisms, but at least with select and poll when the system says you can read from a file descriptor you're only guaranteed that one call to read(2)/recv(2)/... won't block. The implementation of a python read method that returns exactly the number of bytes that you requested will have to call the read system call in a loop and hence might block. There's also to issue of error handling: what happens when the first call to the read system call doesn't return enough data and the second call fails? Does this raise an exception (I suppose it does) and if so, what happens with the data that was returned by the first call to the read system call? All in all I'm not too thrilled by having this behaviour. It is handy when implementing record-oriented I/O, but not when doing line- oriented I/O. BTW. Has anyone looked at the consequences of the new iostack and sock2 for libraries like Twisted? Ronald _______________________________________________ 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
