Toshio Kuratomi <a.bad...@gmail.com> added the comment:
Additionally, the os module is supposed to closely follow the behaviour of the underlying operating system functions: https://docs.python.org/3/library/os.html > The design of all built-in operating system dependent modules of Python is > such that as long as the same functionality is available, it uses the same > interface; [..] The POSIX symlimk function on which this is based has made the decision not to overwrite an existing symlink (See the EEXIST error in https://pubs.opengroup.org/onlinepubs/009695399/functions/symlink.html or man pages on symlink from one of the Linux distros: http://man7.org/linux/man-pages/man2/symlink.2.html ) As with many other POSIX-derived filesystem functions, the technique you propose, relying on atomic filesystem renames) would seem to be the standard method of writing race-resistant code. Due to the mandate for the os module, it feels like that belongs in a utility function in custom code or another module rather than something for the os module. A couple of thoughts on what you could do instead: * A collection of utility functions that fixed race-conditions in filesystem handling could make a nice third party module on pypi. * The stdlib shutil module provides an API that's supposed to be easier to implement common use cases than the os.* functions. Perhaps you could propose your idea to the python-ideas mailing list as a new function in that module and see what people think of that? ---------- nosy: +a.badger _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36656> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com