We're not going to change the default representation without a wider discussion onthe mailing list and a NEP. This will cause a ton of churn for docstring examples in all downstream projects, so we won't pull the trigger on this without a significant consensus from a lot of stakeholders. I have my doubts that we'll get that kind of strong agreement at this time.NEP 51 was the last change of this kind, and it was significantly smaller in scope.

In any case, since there is noshape= argument tonp.array(), this particular choice for__repr__ is probably not going to happen.

In any case, since there is noshape= argument tonp.array(), this particular choice for__repr__ is probably not going to happen.

Hmm, we do give the shape already for shapes that include zeros, and therepr cannot be used anyway to round-trip the array if it is being summarized... Also, I don't actually think this is going to be very disruptive, since the shape is only shown in the rare case that summarization is done (needs a size > 1000). Indeed, in numpy, there is all of one docstring test that now fails. (EDIT: I also checked astropy: also one test failure for a case where it explicitly checks what happens for an array that exceeds the threshold).

Anyway, point taken that this should go by the mailing list (though if the consensus is that this requires a NEP, I will just close this...).

since there is noshape= argument tonp.array(), this particular choice for__repr__

This part does strike me as contrary to what a repr does, so would prefer the version withof shape=(...) hinted at in the mailing list post (given that our repr's cannot be eval'd anyway).

I don't mind this change. It seems right that this is far less impactful than the scalar repr change if it only kicks in when eval round-tripping can't possibly work (if we need a NEP, then just a tiny one for the process of agreeing to it, I think).
Usingshape= as if it was a call is a bit awkward, but not sure that trailingof shape=(...) will read better, so I honestly don't have an opinion on which part.

Given the feedback on the mailing list, I tried implementing adding # shape=... for the cases where the shape is not obvious, but at least locallyspin check-docs now hangs where that happens (innp.set_printoptions docstring): it looks like one may be able to have a comment that does not get checked by the doctest, but not have output that has a comment... I pushed it up so people can see it, but one may have to kill the relevant test run... Any pointers to where these doctests are run?

Current sample output

In [4]: np.arange(1001)Out[4]: array([   0,    1,    2, ...,  998,  999, 1000])  # shape=(1001,)In [5]: np.arange(1001, dtype="i2")Out[5]: array([   0,    1,    2, ...,  998,  999, 1000],      dtype=int16)  # shape=(1001,)In [6]: np.empty((10,2,0), dtype="i2")Out[6]: array([], dtype=int16)  # shape=(10, 2, 0)

OK, I figured out the doctests - it is just very slow if something fails. Must admit that the comment after the array works less well when the array is part of alist, as is the case in the examples for the varioussplit functions. E.g.,

x = np.arange(16.0).reshape(2, 2, 4)np.dsplit(x, np.array([3, 6]))[array([[[ 0.,  1.,  2.],         [ 4.,  5.,  6.]],         [[ 8.,  9., 10.],         [12., 13., 14.]]]), array([[[ 3.],         [ 7.]],         [[11.],         [15.]]]), array([], dtype=float64)  # shape=(2, 2, 0)]

But arguably rare enough that it doesn't matter much. I do like not having theshape argument inside thearray(...) part.

I guess the whole point here is not to be disruptive, otherwise<ndarray data=[...] shape=(...) dtype=float> may have been the better choice.

That# shape=(...) in a list is pretty confusing, since the closing bracket no longer parses :/

There is no constructor for which it makes sense to derive shape from an input object AND specify the shape (ndarray comes closest, but takes a buffer instead of obj), so I suppose it's futile.

Slightly radical, perhaps, but we could add ashape argument toarray(), ignoring it if it matches the object shape, or raise if it doesn't. Kind of useless, but at least then we have some valid excuse to haveshape inside the keyword list. (We'll tell marketing to sell it as a Shape Verifier™.)

Yeah, while anndim orndmax would be useful information, a shape tuple is probably really just useful for verification (even if you allow(-1, 3)); unless you allow reshaping, but that seems too strange to me.
FWIW, my "I don't care", is actually being in favor of using, shape=; I suppose I don't care about the "broken" syntax all that much.

Slightly radical, perhaps, but we could add ashape argument toarray(), ignoring it if it matches the object shape, or raise if it doesn't. Kind of useless,

Actually, not totally useless fordtype=object - it could tell what the desired depth is to which lists of lists should be parsed, i.e., which level theobject is meant to refer to.

Back to this PR, I find the comment inside the list rather bothersome too, and agree with@seberg that the "broken" syntax is not that bad - after all, it is only shown for cases where the data string itself could not be parsed anyway. Shall I go ahead and remove the last commit that tried it?

p.s. I did have one further alternative, which would be to replace the... in summarization with something indicating the number of elements omitted. I felt it was getting too complex, but could revisit...

p.s. I did have one further alternative, which would be to replace the ... in summarization with something indicating the

I remember seeing this discussed as an issue or mailing list post at some point (i.e. someone felt strong about it). Personally, I tend to think it adds much visual clutter (maybe in an html repr where you can reduce the clutter).

Summarizing the more difficult problem: changing the repr breaks doc tests. It seems there are about a dozen in scipy, but only a handful in NumPy. If we go ahead with this, we could recommend projects uselegacy='2.1' if they update to 2.x and their doc tests are broken.

What was the final verdict on where to have the shape information? As a "fake" argument (perhaps to be added later as a real one), or as the comment? If the former, I'll need to remove the last commit.

That# shape=(...) in a list is pretty confusing, since the closing bracket no longer parses :/

I've warmed to the non-existent keyword argument, because of the above.

Agreed. That was also the sentiment at the triage meeting: a fake argument not a comment.

OK, removed the last commit (and rebased), so it is back to a fakeshape argument.

OK, thanks, I added a changelog snippet.

Thanks@mhvk

PSA note for projects using scipy-doctest: upgrade to scipy-doctest==1.5.1, update your doctests to use the new repr, and your doctesting will work on both numpy 2.2 and older versions.

This change broke xarray's printed representation (xrefpydata/xarray#9873) - thank you for providing an escape hatch, but is there a way for me to enable that as a global option?

You can also uselegacy="..." printoptions to avoid the new repr (that defers the problem a bit maybe).

Although, in this case since it seems like a single test, maybe it is just as easy to adapt the test to allow both?