By that logic, you couldn't say anything is ever undefined when it happens in binary machine code, or what spec should apply -- you couldn't say it is C or that it is Python. That level of reductionism doesn't get you anywhere.
Do you not realize that that reductionism is exactly why I don't like your definition of "undefined behavior"?
You are using a non-standard definition of "undefined behavior". In common use, "undefined behavior" is only meaningful relative to a language specification, not an implementation.
Why do you think you are using the common definition when you include implementation bugs as part of UB?
Case 1: A C program overflows an int (which is listed as an undefined behavior in the C spec). Under your definition, and pretty much any other, that program has executed code that results in undefined behavior.
Case 2: A C program overflows an int. That C program happens to be the Python interpreter. Under your definition, based on your responses to previous comments, that did not result in undefined behavior, but was an implementation bug instead.
There is no difference between case 1 and case 2. They are both C programs, so the spec for C determines what is undefined behavior for them. They both did the same thing. Either both are executing code that results in undefined behavior, or neither is.
Case 2 is also an example of an implementation bug if it affects the result of the Python code running in the interpreter.
There is no contradiction. There are two specifications, the C language specification and the Python language specification.
Programs written in Python follow the Python language specification.
When run in CPython, the implementation follows the C language specification.
If the implementation uses C UB, which causes it to be out of compliance with the Python specification, then it is both undefined behavior for C and a failure to follow defined behavior for Python.
It is not undefined behavior for Python.
I have said multiple times that I don't like how your non-standard definition mixed the two together. It is no longer interesting to come up with new ways to restate my statement.
> If the implementation uses C UB, which causes it to be out of compliance with the Python specification, then it is both undefined behavior for C and a failure to follow defined behavior for Python.
That's true, but it's not what you said. You said "the C specification is irrelevant" when I brought up bugs in the C code in CPython, and you said they were implementation bugs but not UB, because the Python spec doesn't define them as UB -- even though the code we were talking about was C! In other words, case 2 in my previous comment.
Now you say "When run in CPython, the implementation follows the C language specification," and "If the implementation uses C UB, which causes it to be out of compliance with the Python specification, then it is both undefined behavior for C and a failure to follow defined behavior for Python."
Those arguments contradict each other. Which one do you believe?
