Re: [Python-ideas] Why is design-by-contracts not widely
On Fri, Sep 28, 2018 at 07:18:54PM +0200, 2qdxy4rzwzuuilue@potatochowder.com wrote:
I see the wink, but I don't see the relevance. Are you agreeing with me or disagreeing? 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. (Although we can often guess, based on assumptions about sensible, non-weird objects that don't do weird things.) But none of that compares to C undefined behaviour. People who think that they are equivalent, don't understand C undefined behaviour. https://blog.regehr.org/archives/213 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html -- Steve
On 9/28/18 7:39 PM, Steven D'Aprano wrote:
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.
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.
On Sat, Sep 29, 2018 at 10:22 AM Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
What should happen here?
Nothing here invokes C's undefined behaviour. Or what about here:
Python has its own set of "well don't do that then" situations. In fact, I would say that *most* languages do. ChrisA
On 9/28/18 8:32 PM, Chris Angelico wrote:
[examples of what Steven would call non-sensible, non-non-weird objects doing non-non-weird things snipped] AFAIK, "AFAIK" is a weasel word: It allows me to proclaim my own ignorance without providing further examples, evidence, or counter examples. :-)
Python has its own set of "well don't do that then" situations. In fact, I would say that *most* languages do.
Yep.
On Sat, Sep 29, 2018 at 10:32:16AM +1000, Chris Angelico wrote:
I'm not fussed about such edge cases. ctypes is not "Python", and other implementations don't support it. Mucking about with the interpreter internals is clear "Here be dragons" territory, and that's okay.
Python has its own set of "well don't do that then" situations. In fact, I would say that *most* languages do.
Indeed, but that's not really what I'm talking about. As I said earlier, Python's semantics are relatively simply in the sense that it is governed by a particular execution model (a virtual machine) that isn't hugely complex, but there are some corner cases which are complex. Overall Python is very rich and non-minimalist. I wouldn't describe it as "simple" except in comparison to languages like C++. BASIC is a simple language, with only two scalar data types (strings and numbers) and one array type, and only a handful of fairly simple flow control tools: if, loops, GOTO/GOSUB. (Of course, modern BASICs may be more complex.) Python has a rich set of builtin data types (ints, floats, strings, bytes, lists, tuples, dicts...), even more in the standard library, OOP, and on top of the familiar BASIC-like flow control (for loops, while loops, if...else) we have comprehensions, with statements and exception handling. (Did I miss anything?) But not GOTO :-) -- Steve
On Sat, Sep 29, 2018 at 9:43 PM Steven D'Aprano <steve@pearwood.info> wrote:
As are all the things that are "undefined behaviour" in C, like the result of integer overflow in a signed variable. They are "Here be dragons" territory, but somehow that's not okay for you. I don't understand why you can hate on C for having behaviours where you're told "don't do that, we can't promise anything", but it's perfectly acceptable for Python to have the exact same thing. AIUI, the only difference is that C compilers are more aggressive about assuming you won't invoke undefined behaviour, whereas there are no known Python interpreters that make such expectations. ChrisA
On Sat, Sep 29, 2018 at 10:15:42PM +1000, Chris Angelico wrote: [...]
They're not the same thing, not even close to the same thing. Undefined behaviour in C is a radically different concept to the *implementation-defined behaviour* you describe in Python and most (all?) other languages. I don't know how to communicate that message any better than the pages I linked to before.
I don't know any other language which has the same concept of undefined behaviour as C, neither before nor after. What does that tell you? If C undefined behaviour is such a good idea, why don't more languages do the same thing? Undefined behaviour allows C compilers to generate really fast code, even if the code does something completely and radically different from what the source code says. Consequently, undefined behaviour in C is a HUGE source of bugs, including critical security bugs, and the C language is full of landmines for the unwary and inexpert, code which looks correct but could do *absolutely anything at all*. The C language philosophy is to give up correctness in favour of speed. I hate that idea. If there was a Zen of C, it would say "Errors should not just be silent, they're an opportunity to win benchmark competitions." -- Steve
On Sun, Sep 30, 2018 at 12:43 AM Steven D'Aprano <steve@pearwood.info> wrote:
Considering that many people here, myself included, still haven't understood what you're so het up about, I think you may need to work on communicating that better. It's still just "stuff you should never do". The compiler is allowed to assume you will never do it. How is that even slightly different from "the CPython interpreter is allowed to assume you won't use ctypes to change a reference count"? ChrisA
On Fri, Sep 28, 2018 at 07:18:54PM +0200, 2qdxy4rzwzuuilue@potatochowder.com wrote:
I see the wink, but I don't see the relevance. Are you agreeing with me or disagreeing? 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. (Although we can often guess, based on assumptions about sensible, non-weird objects that don't do weird things.) But none of that compares to C undefined behaviour. People who think that they are equivalent, don't understand C undefined behaviour. https://blog.regehr.org/archives/213 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html -- Steve
On 9/28/18 7:39 PM, Steven D'Aprano wrote:
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.
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.
On Sat, Sep 29, 2018 at 10:22 AM Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
What should happen here?
Nothing here invokes C's undefined behaviour. Or what about here:
Python has its own set of "well don't do that then" situations. In fact, I would say that *most* languages do. ChrisA
On 9/28/18 8:32 PM, Chris Angelico wrote:
[examples of what Steven would call non-sensible, non-non-weird objects doing non-non-weird things snipped] AFAIK, "AFAIK" is a weasel word: It allows me to proclaim my own ignorance without providing further examples, evidence, or counter examples. :-)
Python has its own set of "well don't do that then" situations. In fact, I would say that *most* languages do.
Yep.
On Sat, Sep 29, 2018 at 10:32:16AM +1000, Chris Angelico wrote:
I'm not fussed about such edge cases. ctypes is not "Python", and other implementations don't support it. Mucking about with the interpreter internals is clear "Here be dragons" territory, and that's okay.
Python has its own set of "well don't do that then" situations. In fact, I would say that *most* languages do.
Indeed, but that's not really what I'm talking about. As I said earlier, Python's semantics are relatively simply in the sense that it is governed by a particular execution model (a virtual machine) that isn't hugely complex, but there are some corner cases which are complex. Overall Python is very rich and non-minimalist. I wouldn't describe it as "simple" except in comparison to languages like C++. BASIC is a simple language, with only two scalar data types (strings and numbers) and one array type, and only a handful of fairly simple flow control tools: if, loops, GOTO/GOSUB. (Of course, modern BASICs may be more complex.) Python has a rich set of builtin data types (ints, floats, strings, bytes, lists, tuples, dicts...), even more in the standard library, OOP, and on top of the familiar BASIC-like flow control (for loops, while loops, if...else) we have comprehensions, with statements and exception handling. (Did I miss anything?) But not GOTO :-) -- Steve
On Sat, Sep 29, 2018 at 9:43 PM Steven D'Aprano <steve@pearwood.info> wrote:
As are all the things that are "undefined behaviour" in C, like the result of integer overflow in a signed variable. They are "Here be dragons" territory, but somehow that's not okay for you. I don't understand why you can hate on C for having behaviours where you're told "don't do that, we can't promise anything", but it's perfectly acceptable for Python to have the exact same thing. AIUI, the only difference is that C compilers are more aggressive about assuming you won't invoke undefined behaviour, whereas there are no known Python interpreters that make such expectations. ChrisA
On Sat, Sep 29, 2018 at 10:15:42PM +1000, Chris Angelico wrote: [...]
They're not the same thing, not even close to the same thing. Undefined behaviour in C is a radically different concept to the *implementation-defined behaviour* you describe in Python and most (all?) other languages. I don't know how to communicate that message any better than the pages I linked to before.
I don't know any other language which has the same concept of undefined behaviour as C, neither before nor after. What does that tell you? If C undefined behaviour is such a good idea, why don't more languages do the same thing? Undefined behaviour allows C compilers to generate really fast code, even if the code does something completely and radically different from what the source code says. Consequently, undefined behaviour in C is a HUGE source of bugs, including critical security bugs, and the C language is full of landmines for the unwary and inexpert, code which looks correct but could do *absolutely anything at all*. The C language philosophy is to give up correctness in favour of speed. I hate that idea. If there was a Zen of C, it would say "Errors should not just be silent, they're an opportunity to win benchmark competitions." -- Steve
On Sun, Sep 30, 2018 at 12:43 AM Steven D'Aprano <steve@pearwood.info> wrote:
Considering that many people here, myself included, still haven't understood what you're so het up about, I think you may need to work on communicating that better. It's still just "stuff you should never do". The compiler is allowed to assume you will never do it. How is that even slightly different from "the CPython interpreter is allowed to assume you won't use ctypes to change a reference count"? ChrisA
participants (4)
-
2qdxy4rzwzuuilue＠potatochowder.com -
Chris Angelico -
Dan Sommers
-
Steven D'Aprano