Repository navigation
BUG: avoid deprecation warnings from numpy.char.chararray when checking types at runtime - #19217
neutrinoceros wants to merge 1 commit into
Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
| except Exception: | ||
| try: # then try to convert it to a strings array | ||
| itemsize = int(recformat[1:]) | ||
| array = chararray.array(array, itemsize=itemsize) |
There was a problem hiding this comment.
this is adjacent and not technically part of the fix, so I can revert this part if prefered. My reasoning is that eliminating chararray as a namespace alias removes noise when grepping for remaining occurences of this class
|
|
||
|
|
||
| def is_chararray(obj, /) -> bool: | ||
| if not hasattr(np, "char"): |
There was a problem hiding this comment.
numpy dev's doc currently says that the entire module may go away in the future, even though it's not deprecated yet, so I'm using this guard clause for future-proofing
|
allowed_failures is expected to pass this time around even though I intentionally didn't fix all of the warnings (see #19216), because the deprecation hasn't landed in nightlies yet. |
| if field.dtype.char in ("S", "U") and not isinstance(field, chararray.chararray): | ||
| field = field.view(chararray.chararray) | ||
| if field.dtype.char in ("S", "U") and not is_chararray(field): | ||
| field = field.view(np.char.chararray) |
There was a problem hiding this comment.
it seems that this single line is responsible for every remaining failures after this patch. I'm not sure whether it's okay to backport the necessary change, as it could be breaking. TBD (possibly in #19216)
There was a problem hiding this comment.
Can we jail this line in a warnings.filterwarnings("ignore", category=DeprecationWarning) via context manager like you did in numpycompat ? That would get rid of the remaining warnings until we are ready for exorcise it for real?
|
So it seems that currently only |
|
Maybe @jorenham could advise? |
|
The plan is to eventually get rid of
Good catch; I agree that we should also deprecate the |
|
@saimn the failures resolved here are now showing up as collection-time errors on |
4a30d22 to
6ccfdd8
Compare
|
tl;dr -- devdeps still red here. What else is needed to make it green again? |
|
Do you want to rebase one more time, and then hopefully @saimn can do a final review, if this PR is ready? Thanks! |
6ccfdd8 to
16f6db2
Compare
|
rebased, and ready |
…ng types at runtime
16f6db2 to
909cc7d
Compare
|
Superseded by #19267 |
Description
ref #19216
fixes the dominant failure mode, and should be backportable