First, thanks for an article on DIP specifically for Python: I think, it adds more choices to the palette!

However, I believe the choice of unrolling the example is a bit unconvincing. If I’d approached this, I’d made it with a composition/aggregation and a bit different inheritance. That is, there would be an abstract API adapter class, and an abstract Robot class, which would “define” the interface. So FenceGuardingRobot would be a subclass of Robot, and so on. So this would respect IS-A, HAS-A, and USE-A correctly: FenceGuardingRobot is a Robot. Robot has a RobotControls. RobotControls use a RobotAPI. (in that sense the example you gave is perfect as it illustrates different relationships found by the modeling.)

And also to remind, that there is still old proven zope.interface, which can be used for DIP and building component architectures.