[Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
Charles-François Natali
cf.natali at gmail.com
Sun Jul 7 09:30:11 CEST 2013
2013/7/7 Cameron Simpson <cs at zip.com.au>:
> On 06Jul2013 11:23, Charles-François Natali <cf.natali at 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
More information about the Python-Dev
mailing list