2013/7/7 Cameron Simpson <c...@zip.com.au>: > On 06Jul2013 11:23, Charles-François Natali <cf.nat...@gmail.com> wrote: > | > I've read your "Rejected Alternatives" more closely and Ulrich > | > Drepper's article, though I think the article also supports adding > | > a blocking (default True) parameter to open() and os.open(). If you > | > try to change that default on a platform where it doesn't work, an > | > exception should be raised. > | > | Contrarily to close-on-exec, non-blocking only applies to a limited > | type of files (e.g. it doesn't work for regular files, which represent > | 90% of open() use cases). > > sockets, pipes, serial devices, ...
How do you use open() on a socket (which are already covered by socket(blocking=...)? Also, I said *regular files* - for which O_NONBLOCK doesn't make sense - represent 90% of io.open() use cases, and stand by this claim. Nothing prevents you from setting the FD non-blocking manually. > And you can set it on anything. Just because some things don't block > anyway isn't really a counter argument. Well, it complicates the signature and implementation. If we go the same way, why stop there and not expose O_DSYNC, O_SYNC, O_DIRECT... When using a high-level API like io.open(), I think we should only expose portable flags, which are supported both on all operating systems (like the 'x' O_EXCL flag added in 3.3) and file types. If you want precise control over the open() sementics, os.open() is the way to go (that's also the rationale behind io.open() opener argument, see http://bugs.python.org/issue12105) cf _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
