@mattip ping, can you take a look at this issue? If it means we need to revert that other PR, than so be it.

Yeah, we should revert or fix PyArray_GetArrayParamsFromObject. That function is told to use a numeric dtype, but gives up and returns an object dtype, the construction proceeds with the numeric dtype anyway, and then counts on the actual assignment to raise if it cannot be done.

We should add somewhere a test that the following succeeds (it is the corner case from #14138 since PyArray_GetArrayParamsFromObject returns a object dtype)

b = np.array([1])
a = np.array([1, b], dtype=int)

@mattip I am good with reverting. Unfortunately this is in 1.17, so we should get it fixed for the 1.17.1 release probably

This is probably a pointless comment, coming so late, but it seems the example given should result in an error. np.array([5]) is a sequence of length 1. Why is this OK

x = np.empty(2)
x[:] = [1, np.array([5])]

but this is not

x[:] = [1, [5]]

???

Was the argument for reversion purely for backward compatibility (i.e. it is not what we want, but the existing behavior has been entrenched for too long to change)?

Yes, the PR inadvertently caused existing code to error without any deprecation or other kind of notice. We could change the behaviour, but should do it in a controlled way.

I agree with @WarrenWeckesser that the behavior should be changed, but also with @mattip that it must go through a deprecation cycle.

@mattip, OK, thanks, that makes sense.

We would have to decide which way we should go: whether to disallow np.array([1, np.array([2])], dtype=int) or to allow np.array([1, [2]], dtype=int). I think elsewhere we decided both should fail.

@WarrenWeckesser there is another dimension to this, because float(np.array([1.])) works. So the method we use to do the conversion to the scalar will not fail here.

Although @nschloe and I would argue that that case shouldn't work either, see #10615

Of course, and I 100% agree with him :). Although we do have some "reverse broadcasting" rules, similar to this, which work probably only because of this behaviour... OTOH, we did pull it off for bools and __index__ and the world did only half break...

We would have to decide which way we should go: whether to disallow `np.array([1, np.array([2])], dtype=int) or to allow np.array([1, [2]], dtype=int). I think elsewhere we decided both should fail.

Indeed, I'm very much in favor of disallowing it .

np.array([1, np.array([2])]) gives array([1, array([2])], dtype=object), and np.array([1, np.array([2])]) gives array([1, list([2])], dtype=object) -- this makes perfect sense, it's exactly what you wrote down. If you allow the conversion to int, you're going down a deep dark hole: What about

np.array([1, np.array([2]), dtype=int)
np.array([np.array([1]), np.array([2]), dtype=int)
np.array([1, np.array([[[[[[2]]]]]]), dtype=int)
np.array([1, np.array([np.array([2])]), dtype=int)

etc.?

Also, note that this conversion is implicit, yikes.

Explicit is better than implicit.

It should all be errors, but I proposed changing __float__, etc. 7 years ago probably and in the end only did __index__ ;). But... since then we got better at keeping the project moving!