Sebastian Berg

Thanks for the update. From my side, I happy if this gets in as is (and if there is feedback we can incorporate it). If we end up with the...

> (before np.reshape it was the only way to do it). Tiny correction: Reshape always existed, but raising an error when it failed with `copy=False` is new (i.e. knowing that...

I can see delaying this, or at least keeping it as a deprecation warning for a very long time. Would it help to advertise the `arr._set_shape(new_shape)` around and advertise it...

FWIW, I think the second PR is good and we could just give it a shot. I would be even happy to advertise `_set_dtype` as **unsafe** "if you use this...

FWIW, we were ~only~ mainly thinking about the Python side one right now. So the C-side version is actually a work-around in that case. In most cases `concatenate(chunks)` is a...

The only small worry I have is that some warnings can be generated very often, if that adds serious overhead that might not be worth it? But, likely it is...

Is there anything holding up removal of the pin? From a quick scan, I would think it is basically a few tiny replacements for things like `np.NaN` which `ruff check...

> since pandas library currently lacks support for NumPy 2.0. Pandas has reasonable support in newer versions since the first release of NumPy (version `2.2.2`). There might be pandas versions...

There seem to be two issues here in a sense. While it made sense to use `asanyarray`, I guess the actual behavior for masked arrays is quite questionable. Now the...

Removing them seems nicest. If we care, maybe a single PR could be nice so it's easy to find them if anyone is ever curios?