Repository navigation
DOC: Update broken_barh example - #29488
story645 merged 1 commit into
Conversation
Sorry, something went wrong.
| 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
Sorry, something went wrong.
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.
Sorry, something went wrong.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
Done. Not really convinced, but it's not worth fighting over.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks!
Sorry, something went wrong.
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
…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.