Charles-François Natali <[email protected]> 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()
else:
# fallback to unlink()
How would that work with dir_fd argument?
- some functions have actually really different prototypes:
for example:
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 <[email protected]>
<http://bugs.python.org/issue14626>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
