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

Reply via email to