yes it's shown in the image, but it's an easy reference point here

Thanks for the suggestion. After thinking about it, I've decided against adding such information for the following reaons:

In the suggested form, I feel it's not obvious thatxranges, yrange map tocpu_1, (5.8, 0.4)) in the line below. This is because (1) it's not clear that the comment refers to the the args of the function and (2) the structural mapping is difficult, because yrange is spelled out in a tuple and is explicit numeric values, whereas xranges is given as a named variable.

Discarded alternatives:

• # broken_barh(xranges, yrange): Even then, the meaning of the yrange tuple is a bit mysterious and readers would have to look up the definition. (On a side node, I'd have expected either (ymin, ymax) or (ycenter, height), but not (ymin, height)).
• # broken_barh(xranges, (ymin, height)): That would be okish, OTOH it feels a bit stupid if we have to repeat the signature as a comment.
• a kwargbroken_barh(cpu_1, yrange=(5.8, 0.4)): While this is instructive, I don't think people would typically use this in real applications.
• a dedicated discussion of the API in the introduction: This feels a bit heavy.

I suppose, I'm stuggling with the API. The relevant (semantic) data are the xranges. The yrange is more or less a visual detail and should not deserve so much attention. IMHO this is a bit of a design flaw, but not solvable in the example. Therefore, I've resorted to writing the example like I would as real-world code, and leave it up to the user to look up the exact API.

# broken_barh(xranges, (ymin, height))

I understand why you feel like it's a hack but I think signature as comment is appropriate here b/c I'm hoping it reduces the cognitive load of parsing the example by explaining what those second (feel kinda arbitrary) numbers are.

Done. Not really convinced, but it's not worth fighting over.

Thanks!