DOC: Update broken_barh example #29488
Conversation
cae42c4 to
92aa1a3
Compare
| arrowprops=dict(facecolor='black', shrink=0.05), | ||
| fontsize=16, | ||
| horizontalalignment='right', verticalalignment='top') | ||
| ax.broken_barh(cpu_1, (5.8, 0.4)) |
There was a problem hiding this comment.
| ax.broken_barh(cpu_1, (5.8, 0.4)) | |
| # xranges, yrange | |
| ax.broken_barh(cpu_1, (5.8, 0.4)) |
yes it's shown in the image, but it's an easy reference point here
There was a problem hiding this comment.
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 that xranges, yrange map to cpu_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 kwarg
broken_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.
There was a problem hiding this comment.
# 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.
There was a problem hiding this comment.
Done. Not really convinced, but it's not worth fighting over.
92aa1a3 to
1bfadee
Compare
IMHO this is more realistic and better looking. I've always been wondering what the previous plot should mean. Note: There's precedence for a similar special-casing on polar Axes for errorbars: https://github.com/matplotlib/matplotlib/blob/3fb9c0961b5c8d5753c88ac37c08cda58a4b7839/lib/matplotlib/axes/_axes.py#L3798
1bfadee to
64535a6
Compare
…488-on-v3.10.x Backport PR #29488 on branch v3.10.x (DOC: Update broken_barh example)
…488-on-v3.10.0-doc Backport PR #29488 on branch v3.10.0-doc (DOC: Update broken_barh example)
Follow-up to matplotlib#29488. It's simpler to count upwards and use `invert_yaxis()` to order top-to-bottom rather than counting backwards
Follow-up to matplotlib#29488. It's simpler to count upwards and use `invert_yaxis()` to order top-to-bottom rather than counting backwards
IMHO this is more realistic and better looking.
I've always been wondering what the previous plot should mean.