COMPAT: numpy object array coercion warnings

[AlexKirko]

Problem description

Since at least a couple hours ago, the Numpy Dev pipeline fails 39 tests:

##[error]39 test(s) failed, 60964 test(s) collected.

I checked and all 39 are like this:

numpy.VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays with different lengths or shapes) is deprecated. If you meant to do this, you must specify 'dtype=object' when creating the ndarray

Full output of one of the tests below.

        True
        >>> a = np.array([(1.0, 2), (3.0, 4)], dtype='f4,i4').view(np.recarray)
        >>> np.asarray(a) is a
        False
        >>> np.asanyarray(a) is a
        True
    
        """
>       return array(a, dtype, copy=False, order=order)
E       numpy.VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays with different lengths or shapes) is deprecated. If you meant to do this, you must specify 'dtype=object' when creating the ndarray

Thanks to @jreback for pointing out we've run into this before, but Numpy reverted the deprecation warning. The original issue was #30043

[jreback]

this is numpy redoing the object array coercion

cc @jbrockmendel
cc @mattip
cc @seberg

numpy/numpy@287a9d0

there was a previous issue about this if want to find / link

numpy reverted the original commit - this is a redo of it

[AlexKirko]

Found the previous issue, I think: #30043. Added to the issue description.

[AlexKirko]

For reference, this is NEP 34, which justified this change.

[AlexKirko]

If anyone wants to take a look, you can check out my error log, while it's still alive. Seems like mostly we directly call np.array or asarray on mixed input, but there is also some stuff in arithmetic operations testing.

[TomAugspurger]

I can take a look at this now.

[jbrockmendel]

@AlexKirko did there end up being a kwarg like np.asarray(ragged, foo=np.ragged_as_object)?

[seberg]

We did not add the special sentinel because it seemed that all of the (larger) downstream packages are handling fine without it. If you find a place where it would help you, we would add it though.