fix: dtype inference in new_known_scalar
closes https://github.com/dask-contrib/dask-awkward/issues/577
if a 0-dim array is passed to new_known_scalar the dtype was inferred to be np.dtype(type(array(...))) which results in object dtype. This PR directly uses the dtype of the input arg if it has a dtype attribute, which is true for array types.
:warning: Please install the to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 92.10%. Comparing base (
8cb8994) to head (6062dc7). Report is 256 commits behind head on main.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@ Coverage Diff @@
## main #578 +/- ##
==========================================
- Coverage 93.06% 92.10% -0.97%
==========================================
Files 23 24 +1
Lines 3290 3598 +308
==========================================
+ Hits 3062 3314 +252
- Misses 228 284 +56
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Needs https://github.com/dask-contrib/dask-awkward/pull/579 to fix the awkward-main ci test
ugh... there seem to be the expectation of dask-awkward that a 0-dim typetracer array is always promoted to a length-1 layout. This is something that does not happen with every other array type. I explicitly fixed this in awkward recently: https://github.com/scikit-hep/awkward/pull/3469#issuecomment-2802584138, but dask-awkward seems to rely on it...
(needs https://github.com/dask-contrib/dask-awkward/pull/580 to be fixed)