Verifiably better, validated Enum for Python

[Chris Angelico]

On Sat, May 27, 2017 at 8:48 AM, Steve D'Aprano
<steve+python at pearwood.info> wrote:
> I don't actually believe that any real compiler will *literally* contain
> code that looks like this:
>
>
> if phase_of_moon(now()) != X:
>     # emit machine code you expected
> else:
>     # erase your hard drive
>
>
> but if one did, that would be perfectly legal and permitted by the standard.
> More realistically, the compiler is allowed to re-arrange your code, delete
> dead code, etc. If it sees undefined behaviour, it is allowed to do the
> same **even if it changes the semantics of the source code**. Hence, the
> compiler might decide that the optimal way to proceed is to erase your hard
> drive.
>
> There's a subtle point here: according to the C standard, code with
> undefined behaviour *has no semantics*, so the compiler isn't really
> changing the semantics of your source code.
>

In the Python spec, is there anything ANYWHERE that makes any stronger
claim about the example I gave? Here's an example:

from ctypes import cast, POINTER, c_int
def demo_function():
    cast(id(29), POINTER(c_int))[6] = 100
    if 29 > 50:
        print(29)

What is a standards-compliant Python interpreter allowed to do?

1) print "29"
2) print "100"
3) pretend the entire body of the function was "pass"
4) erase your hard disk
5) something else

Suppose that someone writes a highly-optimized Python that tracks
global namespace updates (so it knows that these really are the things
imported from ctypes), and does all manner of dead code removal and so
on. Is there anything in the spec that defines exactly what the
semantics of this function are, after you mess around in ctypes? And
if not, then wouldn't it be legal to remove the print call, as dead
code? Show me something that precludes that. Show me something that
makes this any more defined than C's behaviour in those cases you hate
so much.

ChrisA