It is usually folly to disagree with MvL, and yet I am about to do just that.  As stated, I don't believe in the "thin wrappers" theory of os; where would a Windows programmer find the man page to learn how os.access works on their system?

I think os should provide helpful functionality to the programmer, specifically functions that are calling into the system API.  But unlike MvL I would *much* rather see consistent functionality across systems than expose the Python programmer to every fiddling nook and cranny of the local API.  I prefer "Python" programs to "Python-on-Linux" and "Python-on-Windows" programs.

Yet, as much as I'm willing to disagree with MvL, I'm not so sure of myself that I'll check this in against his wishes.  If this idea wins more support in the future, we could still make my proposed change to the interface without breaking backwards-compatibility.  So I volunteer to table the discussion at least for the 3.3 release.

TBH I don't see the benefit of the extra three parameters anyway.  headers/trailers is redundant with os.writev, and the three flags are for shaving off cycles that are lost in the noise of the Python interpreter.  If I ran the circus I'd remove the latter three parameters and have the same interface everywhere sendfile is available.  But I suspect there's no way I can get away with *that* for the 3.3 beta, and once we hit feature freeze I won't be able to remove it.  So I guess we're just going to be stuck with them forever.  *sigh*

--

Let me controversially, hypothetically, propose: if we really want to make raw OS functions available to Python programmers, then so be it, but not in the os module.  We could add an "osx" module, and a "linux" module, and a "freebsd" module, and a "win32" module (though I suppose win32all covers that).  And we could ditch the whole "rename posix to os" shenanigans.