[Python-ideas] Why is design-by-contracts not widely
2QdxY4RzWzUUiLuE at potatochowder.com
Fri Sep 28 20:22:03 EDT 2018
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.
>>> 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.
> 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
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
> (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
More information about the Python-ideas