Refactor numpy array input in as_column

[mroeschke]

Description

Simplifies the numpy array input logic to as_column to be

if object/string dtype like:
    # parse with pandas with inference
elif numeric-like dtype or datelike with nat:
    # parse with pyarrow (due to np.nan/np.nat/nan_is_null handling)
else:
    # create column from buffer

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[wence-]

Suggested change

	is_nat = np.isnat(arbitrary)
	if (nan_as_null is None or nan_as_null) and np.isnat(
	arbitrary
	).any():
	is_nat = np.isnat(arbitrary)
	if (nan_as_null is None or nan_as_null) and is_nat.any():

Let's not compute isnat more often than necessary.

[wence-]

What are the cases we're handling where, and why does this one go via pyarrow whereas the nan_as_null == False or not any(is_nat) goes via as_buffer?

[mroeschke]

In the pyarrow route, we want to convert NaT to NA which pyarrow does nicely be default (nan_as_null=True)

In the buffer route, we want to consider NaT as NA in the mask but maintain NaT as a value (nan_as_null=False)

I'll leave a comment about this

[wence-]

Arguably yes because not all valid datetimes with a coarser resolution can be represented with s resolution.

[vyasr]

Is this intended to still be in draft?

[mroeschke]

Is this intended to still be in draft?

Thanks for checking in on this. Yes, I think there are some failing tests I am still working through

[vyasr]

What happens if we just always use pyarrow here? Do we lose something from non-nullable data that pandas captures better?

[mroeschke]

There are cases where pandas will infer dtype=object into a non-object type that would help match pandas behavior e.g.

In [1]: import cudf, pandas as pd, numpy as np

# e.g a `to_numpy()` round-trip
In [2]: pd.Series(np.array([pd.Timestamp(2020, 1, 1)], dtype=object))
Out[2]: 
0   2020-01-01
dtype: datetime64[ns]

I'll add a comment about that here

[vyasr]

Superfluous else since we're returning above.

[mroeschke]

Good point. Removed

[wence-]

I think this one looks good too, thanks for all the ongoing cleanup work.

[wence-]

This seems "oddly specific". This is something like we have a list of cupy arrays?

[mroeschke]

Correct. I had added this since I thought there was a unit test that would hit this branch. I am no longer encountering that after running the test suite again so I'll actually remove it for now

[mroeschke]

/merge