> I can't think of a situation where it would be useful to do an fsync() > in which you don't want the data to be flushed as far as possible.
Essentially, you are saying that you don't see a use for fsync. If that's the case, then this API should be removed from Python completely. As all others have said: the strong feature of the posix module is that it exposes the operating system calls *as-is*, i.e. without trying to tweak their semantics. If Apple had found it as a useful default for fsync to have the harddisk flushed, they would have put that into the implementation of fsync, instead of coming up with a new API. We don't second-guess operating system vendors (normally). Please understand the enormous relevance of this strategy. If we deviate from it, people might be stuck in chasing the culprit, complaining alternatingly to the OS vendor and to Python. With our strategy to the POSIX module, we can always defer people to the system vendor, and they can easily reproduce the behavior with a C program. (Of course, we also have higher-layer libbraries, were any bugs are our own). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
