> > rename(src, dst) > > Rename the file or directory src to dst. If dst is a directory, > OSError will be raised. On Unix, if dst exists and is a file, it will > be removed silently if the user has permission. The operation may fail > on some Unix flavors if src and dst are on different filesystems. If > successful, the renaming will be an atomic operation (this is a POSIX > requirement). On Windows, if dst already exists, OSError will be > raised even if it is a file; there may be no way to implement an > atomic rename when dst names an existing file. Availability: > Macintosh, Unix, Windows. > > > While I understand that this is an operating system behavior, and the os > module is meant to hold incompatible functionality, I do belive that > most of us developing in posix systems have never checked if a rename > failed because the file already exists. IOW, this will usually be > discovered when the program blows up for the first time in Windows > (that's how Thomas discovered). > > Is it too late to implement the forced rename internally, and leave the > programmer test it with os.path.exists() if he really wants to? > > I know this will cause incompatibilities in programs which expect the > current behavior. OTOH, programs that expect this behavior are already > broken in any posix system. -1. The Unix semantics can't be properly emulated on Windows, because it is guaranteed to be *atomic*. Python can't know whether an applications that blindly assumed Unix semantics is relying on the atomicity; if the application needs this, doing a remove() first under the cover would be a grave error (especially more grave since the potential data loss is unlikely to be found through testing). --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4