[issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count
report at bugs.python.org
Sun Apr 29 18:35:18 CEST 2012
Charles-François Natali <neologix at free.fr> added the comment:
Well, it always boils down to the same problem: should we offer thin wrappers around underlying syscalls or offer higher-level functions?
I personally think that offering mere wrappers around syscalls doesn't make much sense: Python is a very-high level language, and so should its library be.
Now, I'm in favor of adding optional argument to tune the behavior with regard to symlinks, however I'm skeptical about merging regular syscalls and *at() syscalls, for the following reasons:
- *at() syscalls are not portable: if it's not supported, what's remove(path='toto', dir_fd=fd) supposed to do? Throw an exception?
- it's not clear how one's supposed to check that the functions are available: right now, one can do
if hasattr(os, 'unlinkat'):
# use unlinkat()
# fallback to unlink()
How would that work with dir_fd argument?
- some functions have actually really different prototypes:
rename(<old path>, <new path>) -> renameat(<old dir_fd>, <old path>, <new dir_fd>, <new path>)
trying to coalesce them into a single function will lead to awkward and ugly API: some arguments will be exclusive (which is almost always a sign of a bad API), and the order sounds really wrong:
stat(path, *, followlinks=True, dirfd=None)
is backwards, it should be
stat(dirfd, path, *, followlinks=True)
since, `path` is relative to `dirfd`.
Actually, the proper way to do this would be to use overloading, but Python doesn't support it (and even if it did, I think overloading would probably be a bad idea anyway).
- taking for a second the point of view of a user that has never heard of the *at() family, if I come across such a function:
chmod(path, mode, *, followlinks=True, dir_fd=None)
I'll probably have to think some time to understand what the hell is the last dir_fd argument. Renaming, removing a file is simple and direct, so should the API be.
- finally, although useful, the *at() family is a really poor and confusing API, which will likely be used by less than 0.1% of the overall Python users. Complicating the whole posix module API just to shave off a few functions is IMHO a bad idea.
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list