On 9/28/18 8:12 PM, Chris Angelico wrote:
On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing <greg.ew...@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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
