Consider numpy scalars and 0d arrays as scalars when padding

[keewis]

As discussed in #9645, this adds getattr(pad_value, "ndim", None) == 0 to the condition that checks if the pad value is scalar.

While implementing the code, I noticed that while 0d arrays are definitely not instances of Number, for numpy scalars this is a bit more tricky: scalars with int / float / complex / timedelta64 dtypes are already considered as scalars (the isinstance check evaluates to True), while datetime64, bool_, str_ and probably others are not.

As such, I'm not sure what the best way to test scalars would be. I'd be tempted to just write new tests specifically for expand_pad_value, but that might not fit the existing test strategy (which for dask.array.creation seems to just check the high-level functions).

• Closes padding datetime arrays with missing values #9645
• Tests added / passed
• Passes pre-commit run --all-files

[GPUtester]

Can one of the admins verify this patch?

Admins can comment ok to test to allow this one PR to run or add to allowlist to allow all future PRs from the same author to run.

[ncclementi]

add to allowlist

[keewis]

since I couldn't come up with a better way to test this, I decided to just add a new test that checks a bunch of different dtype / scalar or 0d array combinations for mode="constant". Not sure if we'd need to check other modes as well, but then testing expand_pad_value directly would probably be a better idea.

[keewis]

gentle ping. I think the failing tests are unrelated (some FutureWarning for dask.dataframe), so this should be ready for review.

[keewis]

gentle ping. @jrbourbeau, this is ready for a review.

[keewis]

gentle reminder that this PR is still waiting for a review (and the only actual change is a single line). It would be really great if this could be merged any time soon, because that would allow fixing a few bugs in downstream libraries (most notably xarray and datatree).

[jrbourbeau]

Apologies for the lack of response @keewis. Taking another look now

[jrbourbeau]

Thanks @keewis -- this is in. Again, apologies for the delayed response