I think this raises the more fundamental question of whetherintersection should ever returnNone in the first place.

Certainly I missed that possibility when implementing#24976, so if wedon't change it that type hint should be corrected, and also affects some other places where an intersection is returned directly (e.g.get_tightbbox, where the docstring doesn't acknowledge it can returnNone either).

We in one place (internally) rely on the Falsiness of the non-overlap case.

My suggestion (and I want some buy-in from other maintainers before a final decision is made, perhaps@timhoffm as API lead, in particular) would be to implement__bool__ onBbox:

def__bool__(self):returnself.x1>=self.x0andself.y1>=self.y0

This would makeBbox.null() Falsey (as well as any other bbox where either x or y has negative length) and allow simplifying theintersection code such that it never returnsNone, thus simplifying the return type while retaining (most) behavior (aside fromBbox.intersection(a, b) is[ not] None checks)

There are a small handful of internal checks which dois None on a bbox (potentially) computed viaintersection e.g.if clipped_bbox is None: inimage.py andvar = get_tightbbox(...) ... if var is not None in a few places. These could be replaced with simplyif [not] var:, so the fix is pretty easy and actually backwards compatible (on the condition that the direct output of intersection is fed in, as any case that results in a Falsey bbox would result inNone from intersection).

I did not see any downstream packages that have similar checks, though certainly not an exhaustive search. Astropy and PIL have somebbox is None checks, but pretty sure they are referring to their own Bbox implementations when they do, not ours (especially for PIL, of course).
Astropy does have a short circuit inWCSAxes.get_tightbbox which returns None directly.

Doing so at theintersection level would render this code change proposed here unnecessary, as desired behavior would simply fall out from intersection calculation.

@ksunden - Your proposal is quite orthogonal to the above issue. (It would open up another type of fix, but only after a deprecation period)

1. bool-evaluating a null-object to false totally makes sense. Slight unclarity should the half-null boxes with one finite dimension also be false or not? I have no clear opinion on that, which is likely because I don't know in which contexts they appear.

2. Returning null boxes instead ofNone.

SinceBbox.null() already defines the null-object concept, we could use it. (I'm generally very torn on the use of null-objects in Python). However, we have a significant compatibility barrier:

https://matplotlib.org/stable/api/transformations.html#matplotlib.transforms.BboxBase.intersection

Return the intersection of bbox1 and bbox2 if they intersect, or None if they don't.

is public API and very clear about the return value. Any user will canonically checkintersection() is not None and notnot intersection(). If we want to go there we need a regular deprecation cycle (and it's nasty because we cannot runtime-warn on it).

I've no clear how widespread this is used, but would imagine that there's a bit of user code out there, that would be affected.

Additional question: How is consistency across other functions returning bboxes. Do we have other cases that can return invalid boxes? If so, do they return null() or None?

Overall:

• (1) yes;
• (2) I'm sceptical on the cost-benefit ratio.

I agree with@timhoffm 's analysis and that we should handle the wider issue independently of this PR.

None of the below is critical, because fixing the RuntimeError is most important. But

When running the code from the test I get a warning log from

This is not helpful for the end user, but I don't know whether we can do something about it. - Does a warning from a deep burried draw() function make sense at all? Maybe we should switch to info or debug.

Edge case: Setting the limit to the bar border still draws the label:

import matplotlib.pyplot as plt_, ax = plt.subplots()last = 0for label, value in zip(['a', 'b', 'c'], [10, 20, 50]):    bar_container = ax.barh('col', value, label=label, left=last)    ax.bar_label(bar_container, label_type='center')    last += valueax.set_xlim(None, 30)#plt.savefig(tmp_path / 'test')plt.show()

None of the below is critical, because fixing the RuntimeError is most important. But

When running the code from the test I get a warning log from

matplotlib/lib/matplotlib/text.py

Line 725 inb86ebba

_log.warning("posx and posy should be finite values")

This is not helpful for the end user, but I don't know whether we can do something about it. - Does a warning from a deep burried draw() function make sense at all? Maybe we should switch to info or debug.

Edge case: Setting the limit to the bar border still draws the label:

import matplotlib.pyplot as plt_, ax = plt.subplots()last = 0for label, value in zip(['a', 'b', 'c'], [10, 20, 50]):    bar_container = ax.barh('col', value, label=label, left=last)    ax.bar_label(bar_container, label_type='center')    last += valueax.set_xlim(None, 30)#plt.savefig(tmp_path / 'test')plt.show()

I tried this approach to apply some margin on the right hand side of the figure:
ax.set_xlim(right=ax.get_xlim()[1]+1.0, auto=True)
it fixes the runtime error at least!