[Python-ideas] Why is design-by-contracts not widely adopted?

[Dan Sommers]

On 9/28/18 8:12 PM, Chris Angelico wrote:
> On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing <greg.ewing at 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.