PR summary

Closes #32127.

Line3D.set_data_3d documents its parameters as array-like, checks only that each argument is iterable, and stores them as given:

for name, xyz in zip('xyz', args):
    if not np.iterable(xyz):
        raise RuntimeError(f'{name} must be a sequence')
self._verts3d = args

draw then read self._verts3d[0].shape, so a list raised AttributeError: 'list' object has no attribute 'shape'.

fig = plt.figure()
ax = fig.add_subplot(projection="3d")
(line,) = ax.plot([0.0], [0.0], [0.0])
line.set_data_3d([float("nan")], [float("nan")], [float("nan")])
fig.canvas.draw()

The access lives inside the invalid-scale masking branch, so a finite list draws and only an invalid coordinate reaches it. That is why it went unnoticed.

The requirement arrived in two steps. d18c52b introduced _verts3d[0].shape behind if self._axlim_clip:, so it applied only to lines that had opted into clipping. 629d396 then added _scale_invalid_mask, which runs unconditionally, and changed the guard to if np.any(scale_mask):. Nothing about set_data_3d changed; the block consuming what it stores did. 3.10.9 has neither and draws all of these.

NaN is not the only trigger. On 3.11.1 with lists in _verts3d, AttributeError also comes from inf, from a value <= 0 on a log scale, and from an out-of-view point with axlim_clip=True. Tuples fail the same way. The log-scale row is the awkward one: _scale_invalid_mask was added so that data outside a scale's valid domain is ignored rather than breaking the plot, and here it raises instead.

np.shape accepts both, and unlike converting in the setter it leaves what get_data_3d() returns unchanged, so a caller that reads back what it passed still gets it.

PR checklist

• Has pytest style unit tests, and pytest passes
• New features are documented, with examples if plot related — n/a, this is a bug fix with no API change
• Documentation is sphinx and numpydoc compliant — n/a
• Added an entry to doc/users/next_whats_new/ if major new feature — n/a
• Documented in doc/api/next_api_changes/ if API changed — no API change; this makes the documented contract hold

Verification

Against a released 3.11.1 with only art3d.py replaced, so the comparison is like for like:

Note on a sibling occurrence

Path3DCollection.do_3d_projection has the same pattern one screen down:

mask = np.broadcast_to(mask, (len(self._offsets3d), *self._offsets3d[0].shape))

I left it alone. _offsets3d is private and its public writer routes through juggle_axes(xs, ys, np.atleast_1d(zs), zdir) with xs, ys coming from get_offsets(), so it holds arrays; ax.scatter with a NaN draws fine. Assigning _offsets3d a tuple of lists directly does reproduce the same error, so it is the same defect, just not one reachable through public API. Happy to include it here if you would rather the two were consistent.

I checked the other users of _scale_invalid_mask and _viewlim_mask the same way, driving each through its public entry point with list input and a triggering coordinate: Line3DCollection, Poly3DCollection, ax.scatter, ax.text, plot_surface and ax.plot all draw, because each converts to arrays on the way in. The two Line3D setters are the exception, and they are the documented way to update an existing 3D line in place. Details in #32127.

How this was found

Downstream code updating a rocket marker each frame, written against the advice in #22308 to use set_data([a], [b]) and set_3d_properties([c]). That produces exactly this state, and it drew on 3.10 and raised on 3.11 the moment a coordinate went non-finite, which happens before the object being plotted has a position.

Update: the test was covering one way in, of three

set_data_3d with a list of NaN on a linear scale was the only case. The masking branch is entered when a coordinate is non-finite, when it is outside the active scale's domain, or when it is outside the view limits with axlim_clip enabled. The last two need no non-finite value at all: 0.0 on a log axis reaches it, and so does a finite in-domain point that is simply off screen. My first commit message said only a non-finite coordinate could get there, which was wrong.

Parametrized over list and tuple, and over five ways in: NaN, inf, a finite value outside a log domain, a finite value masked by axlim_clip, and a multi-vertex line where only one vertex is masked.

Backport

3.11.1 is affected, so this wants a v3.11.x backport once it lands. Flagging rather than labelling, since I cannot set milestones.

Two findings from the same audit, filed separately

Neither belongs in this PR, and neither blocks it.

#32129 is the one I would look at next. ScaleBase.val_in_range calls limit_range_for_scale with an array, and when a third-party scale is written for scalars, which is the shape LogScale.limit_range_for_scale itself uses, the except (TypeError, ValueError) fallback returns "nothing is in range". _scale_invalid_mask negates that, so every point on the axis is masked and every 3D artist silently disappears with ordinary finite data. Measured: line 0/4 and scatter 0/4 finite points after projection, no warning, no exception. Silent deletion seems worse than the crash this PR fixes.

Line3D.set_data_3d also accepts two or four coordinate sequences, because zip('xyz', args) truncates silently. The failure then surfaces at draw time as TypeError: _scale_invalid_mask() missing 1 required positional argument, which names an internal function at the user. Pre-existing and unrelated to the masking change; I have not filed it separately, and can if it is wanted.