GeezerVison

While Matplotlib normally represents lists of (x, y) coordinates as (N, 2) arrays [...], axisartist uses the opposite convention of using (2, N) arrays (or size-2 tuples of 1D arrays)
Note that I intentionally mostly didn't touch (transpose) public-facing APIs for now, this may happen later.

On a side-note, we can (and maybe should?) distinguish/handle (N, 2) arrays and (size-2 tuples of 1D arrays) for the API. That (size-2 tuples of 1D arrays) is technically a 2D array-like does not mean we have to interpret it in the same way as a 2D array.

Of course internally, (N, 2) arrays are the way to go, but for user-facing API not all array-likes have to be interpreted the same way. For example, one currently has to do

x = np.linspace(0, 6.28)
y = np.sin(x)
points = np.array([x, y]).T
Path(points)

The np.array(...).T feels quite awkward and is something that new users have to learn.

(Disregarding backward compatibility for now), I think it's not unreasonable to also allow

points = (x, y)
Path(points)

Note that the distinction would be very specifically limited to tuple of array-like, i.e. an implementation would likely coerce using

if isinstance(points, tuple):
    # assume tuple of coordinate arrays (x, y, ...)
    points = np.array(*points).T

The np.array(...).T feels quite awkward and is something that new users have to learn.

Personally I always write np.column_stack([x, y]) which makes more semantic sense to me.

Note that the distinction would be very specifically limited to tuple of array-like, i.e. an implementation would likely coerce using

There are currently some APIs (e.g., boxplot) that distinguish between lists (or tuples) of lists and 2d ndarrays, and they cause endless confusion... See e.g. #2539, #8092.

Personally I always write np.column_stack([x, y]) which makes more semantic sense to me.

Indeed.

There are currently some APIs (e.g., boxplot) that distinguish between lists (or tuples) of lists and 2d ndarrays, and they cause endless confusion... See e.g. #2539, #8092.

Noted. Though I'm unclear how endless this trouble actually is. #2539 is a single report. #8092 is specifically on array of arrays, which is not really specified in the docs. I'd consider the implementation a bug and would simply disallow array of arrays. Also note that specifically boxplot() must support different number of data points per box and thus a 2D array is not sufficient, OTOH data are often in the form of 2D arrays, so accepting that is reasonable as well (and related but without discussion aggregating along columns).

I don't want to open a full discussion now. I agree with the scope of the PR that we don't want 2D (2, N) arrays.