> Is there any reason not to change this?
Apart from the effort it makes to talk about it, and to review and
apply the patch? No.
Regards,
Martin
P.S. You really do need to trust that the system calls get forwarded by
Python to the system as-is, with no additional trickery. If there is
additiona
Unless documented otherwise, the Python wrappers for system calls are
as low-level as possible, sticking as close to the system call
semantics as possible.
I do think you may be reading too much into the whole thing.
On Thu, Jan 8, 2009 at 9:05 AM, Mike Coleman wrote:
> One problem is that API w
One problem is that API wrappers like this sometimes include extra
functionality. When I ran across this example, I wondered whether the
Python interface had been enhanced to work like this
# set these three flags
rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NDELAY)
rv = fcntl.fcntl(f, fcn
Well my Linux man page says that the only flags supported are
O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, and O_NONBLOCK; and all of
those are typically off -- so I'm not sure that it's a mistake or need
correcting. These APIs should only be used by people who know what
they're doing anyways; the exa
In the doc page for the fcntl module, the example below is given.
This seems like an error, or at least very misleading, as the normal
usage is to get the flags (F_GETFL), set or unset the bits you want to
change, then set the flags (F_SETFL). A reader might think that the
example below merely set
