This shows the method resolution order associated with bools. If you invoke a method on a bool object, it'll research the bool, then the int, then the object namespaces, looking for a case-sensitive match.[*]
Here, the method resolves in the int namespace:
>>> True. __neg__() -1
The __neg__ method belongs to the int type, which is innocent of True or False, so the result is -1 (the negative of 1). The "under-under" notation signifies an overloadable method, invokable using alternate syntax, in this case - (just as + invokes __add__, / invokes __div__ and so on).
If resolution fails after the entire __mro__ track has been run, then an exception is raised, e.g:
Traceback (most recent call last): File "<pyshell#27>", line 1, in -toplevel- True.bark() AttributeError: 'bool' object has no attribute 'bark'
Note that when a computer language such as Python hits a glitch, it "throws" a type of object which may then be "caught" (Java jargon).[**]
This is unlike traditional math notations, which do not formally categorize errors in preparation for their handling. In traditional math, whoever is grading the paper applies some idiosyncratic markup, often hard to decipher.
In the real world, where machine methods must be used, given the huge demand for fast and reliable computation, what to do in the case of exceptions is a non-trivial question deserving of more well-engineered, more consciously thought-out solutions.
Early computers used to crash when a divide-by-zero occurred, which was maybe OK given the single process at stake (like, why keep running if it's so severely flawed?).
But in today's multi-tasking systems, no mere process is allowed to bring down the OS. Other processes containing no errors shouldn't be stopped or even slowed down, just because one tiny piece of memory is having some internal consistency problems.
Most modern machine codes know how to retain executive control even when the impossible happens (more often than we'd like).[***] Provided humans have taken proper advantage of the aforementioned error-trapping features, disaster may be averted, by dint of a graceful dodge.
Of course in practice retaining control over the logic is not always feasible. A stray exception percolates to the operating system level and the process is killed, perhaps with explicit notice to the user. Plus hardware glitches may subvert whatever clever software traps have been laid. Someone trips over the power cord and turns off the juice, oh well (exceptions happen).
So another reason we advance Gnu Math within our error prone world is its more focused attention on mistakes and what to do in the case of.
Whereas traditional mathematicians may scribble comments or mutter curse words when a computation fails to pan out, gnu mathematicians need to think more in terms of catching and handling these curve balls in life, perhaps logging them for later forensic analysis, but without crashing and burning so easily.
We need to be less brittle, more flexible, more pneumatic in our thinking -- but without losing the advantage of unambiguous formalisms. Machine codes help us recognize and deal with the reality of mistake-making. We incorporate this activity into the normal course of our business day, even as we strive to compensate through bug fixing, refactoring, and other self-disciplines.
* you need a method resolution order especially when multiple inheritance is permitted (as is the case in Python). Multiple inheritance may lead to diamond patterns, wherein a single parent's two children in turn have a single child. So which sibling should be consulted first? Formalizing the answer helps keep different implementations consistent.
** Here's the class hierarchy for Exception types, from the current version of Python (note there's even infrastructure for handling futuristic notation still in the process of being phased in):
[***] machine code: historically, only the "closest to the metal" stored programs were considered as such, a rung beneath assembler, but here I'm just referring to codes designed to run on machines, no matter how high level.