Last post, I put forward the hand-wavey idea that contrary to typical object-oriented practice, Python would allow you to do something very like method inheritance. I wanted to see how easily my idea would translate into Python code, and so after a few false starts, here's what I came up with:

I've handled the idea of "interrupts" - e.g. not completing the action because an earlier condition precludes it - by implementing the methods interrupt_after and should_fire. Running the script should produce this output:

Working Lever was touched!
Working Lever was pulled!
Working Lever was lever-pulled!

Electrified Lever was touched!

The working lever handles the touch event, then the pull event, then the "lever-pull" event as expected. The electrified lever handles the touch event, and immediately interrupts - it doesn't handle the pull, lever-pull or electrified-lever-pull events, but jumps straight to the "ZAP" code inside ElectrifiedLeverPull.go. This means there's no danger of the electrified lever actually being pulled like a regular lever - the user can't just pull it and accept whatever damage the electric shock deals them.

One change I'd like to make is a similar "interrupt before" method - if, for instance, the item is behind a forcefield, and we want to interrupt before handling any touch events, it'd be nicer to say "interrupt before touch" than "interrupt after Event" or something equally nonsensical.

It's reassuring to see that the idea seems to work for trivial cases. I'm going to continue expanding it out, especially with regard to how the events will actually apply to objects in the world.