On 9/28/18 8:12 PM, Chris Angelico wrote:
On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Chris Angelico wrote:
It is still fundamentally difficult to make assertions about the file system as pre/post contracts.
When you consider race conditions, I'd say it's impossible. A postcondition check involving the file system could fail even if the function does its job perfectly.
I guess that depends on the meaning of "contract". If it means "there is a guarantee that this is true after this function returns", then yes, the race condition means it's impossible. But as a part of the function's declared intent, it's fine to have a postcondition of "the directory will be empty" even though something could drop a file into it.
But if it's the latter... contracts are just a different way of defining unit tests.... and we're right back where we started.
At the risk of pedantry (on a Python list? I'm *shocked*): I call BS on any contract that requires on entry or guarantees on exit the state of the file system. At best, a function can guarantee that it will make (or made) a request to the OS, and that the OS returned "success" before the function continued. Then again, a function that guarantees to work in a particular way based on some condition of the file system would be okay. For example, a function might claim to create a temporary file with some content *if* some directory exists when the function tries to create the temporary file. But as I think both of you are claiming, the best that function can guarantee on exit is that it asked the OS to write to the file, and that the OS agreed to do so. The function cannot guarantee that the file or the content still exists when the function finally returns.