astropy: Numpy dev: 2 failing tests (string aggregation suddenly works)

example logs

Reprod:

pytest astropy/table/tests/test_groups.py::test_table_aggregate

log extract

E       Failed: DID NOT WARN. No warnings of type (<class 'astropy.utils.exceptions.AstropyUserWarning'>,) were emitted.
E        Emitted warnings: [ UserWarning('Warning: converting a masked element to nan.'),
E         UserWarning('Warning: converting a masked element to nan.')].

What seems to be happening is that we get both expected warning but the second one doesn’t have the expected category and is a plain UserWarning instead of AstropyUserWarning

This bisects to https://github.com/numpy/numpy/pull/26012, which was backported to numpy 2.0.x in numpy/numpy@691514a (#26047) .

I’ll dig some more to see if we should (and can) fix this on our side, and will report otherwise.

About this issue

  • Original URL
  • State: closed
  • Created 3 months ago
  • Comments: 17 (17 by maintainers)

Most upvoted comments

I think we should just close this issue once the fix has hit the nightlies. Then for rc1 we can see whether there still is a problem (by that point, we probably should adjust our own workflows to run 2.0.0rc*` as well).

My understanding is that numpy dev silently promoting plain Python strings to a new dtype is considered a bug so I expect it will be fixed upstream and that we won’t need to do anything more on our side. I’ll keep this issue updated whichever direction is actually taken !

For posterity, the incompatibility I was mentioning is fixed in #16229, is the only one I found, and isn’t directly related to the present issue, so closing this now !

From the numpy discussion, it sounds like regular string dtype will still not support addition, but the new StringDType will.

This would mean that we don’t need to fix anything in astropy for the time being, right ?

I’m certainly fine with letting that work in tables too.

Good ! As you said, np.mean won’t be supported any way so, with that in mind, I think the existing phrasing in our docs is actually future proof, so again, nothing to do there !