Interesting. Could we push this up to the Artist level?

Tagged an 2.1.1, but I suspect that the safest thing will be to revert the default and hold something like this for 2.2.

As wrote in the comment I was really hoping to put this at the level of BarContainer but that guy has no control over drawing :-( so I put it at the lowest possible level.
I'd rather have the patching of the scale happen around the smallest possible of code (e.g. here it's a single statement), which is tricky to do at the draw artist level (because each artist will have its own way of interacting with the transform). So you'd effectively need to go through the draw() implementation for each Artist subclass, which I'm too lazy to do now.

Edit: But I guess the same mechanism can be helpful for log-scale errorbars that go below zero (not that they're particularly physically meaningful but I'm sure we're going to get a bug report about that...).

Edit^2: Now also implemented for log-scale errorbars and fill_between, and added tests.

Looking at this again, I feel that the correct behavior is indeed to clip by default. However, the clipping should not be done by the scale machinery. Instead, it should be done at the renderer stage: when then renderer gets a point at (x, inf) (fully transformed, in pixel coordinates), it should plots it at (x, some-large-number) (note that right now renderers already need to implement this because otherwise this will overflow the C-level variables used by the renderer, e.g. https://github.com/matplotlib/matplotlib/blob/master/src/_backend_agg.h#L615). So you get clipping, but without the issue raised in #8045 and #8783: the clipping always occurs at some large number in pixel coordinates (thus outside of the image) rather than in value coordinates.

If it were only up to me, I would even suggest doing this independently of the scales machinery, so that even in linear scales, something like plt.plot([1, 1], [-np.inf, np.inf]) draws a vertical line at x=1. Wouldn't that behavior actually make sense? (Yes, I know, back-compatibility, yada yada.)

See also #9477 which implements something similar, which I think works better than the strategy of this PR.

I also like #9477 better.

👍 for supporting plt.plot([1, 1], [-np.inf, np.inf]) for 2.2

You realize that would be a major change in behavior, right? 😉

There is a question of how wrong the slope will be for ax.plot([1, 2, 3], [1, np.inf, 1]).

Closing in favor of #9477

For ax.plot([1, 2, 3], [1, np.inf, 1]) you'd get a vertical line starting at (1, 1) going upwards to infinity and another one going downwards from infinity to (3, 1) (I think that's pretty clear?).

The main question is what to do with (inf, inf). Realistically, this can either be treated as nan, or as a point infinitely away at an angle of 45°. I think I mildly favor the second posibility, as this allows e.g. filling [(0, 0), (0, inf), (inf, inf), (inf, 0)] to mean the positive quadrant, but I could easily be convinced otherwise.