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

[Dan Sommers]

On 9/28/18 7:39 PM, Steven D'Aprano wrote:
> On Fri, Sep 28, 2018 at 07:18:54PM +0200, 2qdxy4rzwzuuilue at potatochowder.com wrote:
>>
>> On 9/28/18 12:45 PM, Steven D'Aprano wrote:
>>> On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote:
>>>
>>>> C and Python (currently) are known as simple languages.
>>>
>>> o_O
>>>
>>> That's a usage of "simple" I haven't come across before. Especially in
>>> the case of C, which is a minefield of *intentionally* underspecified
>>> behaviour which makes it near to impossible for the developer to tell
>>> what a piece of syntactically legal C code will actually do in practice.
>>
>> s/C/Python/
>>
>> s/underspecified/dynamic/
>>
>> ;-)
> 
> I see the wink, but I don't see the relevance. Are you agreeing with me
> or disagreeing?

I agree that Hugh's use of "simple" is unfamiliar.

I disagree that C is is a bigger offender than Python when it comes to a
developer telling what a piece of syntactically legal code will actually
do in practice.  If that's not what you meant by "Especially in the case
of C...," then I mis-interpreted or read too much into your wording.

> Python is "simple" in the sense that the execution model is *relatively*
> simple, but its not a minimalist language by any definition. And as you
> say, the execution model is dynamic: we can't be sure what legal code
> will do until you know the runtime state.

That's my point:  What you emphasized about C can be applied equally to
Python.  In C, it's because the standard is intentionally
underspecified; in Python, it's y because the language is intentionally
dynamic.

When you said "underspecified," I didn't make the leap to "undefined
behaviour" (although I think I know from past experience how you feel
about C and its undefined behaviour).  Instead, I jumped to things like
the ambiguity in the size of an int, or the freedom the compiler has to
pack/align struct values or implement integers as something other than
two's complement.

> (Although we can often guess, based on assumptions about sensible,
> non-weird objects that don't do weird things.)

Again, the same is true of C.  In Python, weird objects might override
getattr; in C weird objects might point to hardware registers, or depend
on implementation specific detail(s).

> But none of that compares to C undefined behaviour. People who think
> that they are equivalent, don't understand C undefined behaviour.

Well, yes:  Some syntactically legal C results in nasal demons, and some
of that code is harder to spot than others.  AFAIK, syntactically legal
Python can only do that if the underlying C code invokes undefined
behaviour.