-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Make parsing deprecated units obey parse_strict
#18536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The updated tests demonstrate that parsing deprecated units with `u.Unit(..., parse_strict=...)` ignores the `parse_strict` argument.
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.
|
👋 Thank you for your draft pull request! Do you know that you can use |
@@ -356,7 +356,7 @@ def test_write_jybeam_unit(tmp_path, recwarn): | |||
t = Table( | |||
{ | |||
"flux": [5 * (u.Jy / u.beam)], | |||
"foo": [0 * u.Unit("Crab", format="ogip")], | |||
"foo": [0 * u.Unit("Crab", format="ogip", parse_strict="warn")], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not obvious to me why a test about writing a VOTable should assert that parsing the string "Crab"
with the "ogip"
format emits a warning, but that is what the test does.
cls, | ||
unit: str, | ||
detailed_exception: bool = True, | ||
deprecations: Literal["silent", "warn", "raise"] = "warn", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect the new parameter will be helpful for #18304.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be, and perhaps the best way forward would be to try to solve #18304 first (which can be done for 7.2). Though one of the options there has to be "convert".
The `astropy` unit parsing machinery recognizes deprecated units (e.g. `u.Unit("erg", format="vounit")`) and emits warnings about them, but so far it has not been possible to suppress those warnings by specifying `parse_strict="silent"`, nor has it been possible to convert the warnings to errors with `parse_strict="raise"`. Now `parse_strict` works as expected, but because the default value is `"raise"` then `astropy` can raise errors where it previously succeeded (with warnings). Previous behavior (regarding deprecated units) can be ensured by specifying `parse_strict="warn"` explicitly.
508ea6f
to
d829da9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me.
We don't have a good mechanism to keep PRs updated if they aren't going into the current release... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is going to give a lot of noise for users - if we go this route, we at the very least have to check that reading existing VOTable with deprecated units is not giving any errors, neither in our own code nor downstream -- I don't think it is OK to force people to change code just because of possibly deprecated units.
As I wrote in #18532, to me it seems more logical that by default we simply recognize things like erg
and Angstrom
which are used in the wild and not give any warning - the user cannot really help it anyway in typical situations. Rather, we should warn/error/convert on output (#18304).
I guess another way of thinking about this, is that it has little to do with parsing: the unit can easily be recognized and are not misspelled, so perhaps this needs a new argument altogether (or a new possibility for parse_strict
so that the default behaviour does not change). Though I think my preference is simply to accept deprecated units on input, as I don't see any real point in warning or erroring (i.e., if someone truly wanted to be sure a unit is not deprecated, they'd have to try to roundtrip; we could provide a separate function for that).
Marking as "request changes" just because I want to be sure we don't accidentally merge before reaching a conclusion here.
cls, | ||
unit: str, | ||
detailed_exception: bool = True, | ||
deprecations: Literal["silent", "warn", "raise"] = "warn", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be, and perhaps the best way forward would be to try to solve #18304 first (which can be done for 7.2). Though one of the options there has to be "convert".
Description
The
astropy
unit parsing machinery recognizes and emits warnings about deprecated units, but (as reported in #18532) these warnings do not obeyparse_strict
. Making deprecated units obeyparse_strict
is not very complicated technically, but because by defaultparse_strict="raise"
thenastropy
can start raising errors where it previously succeeded (with warnings). Because of this backwards-incompatible change I have tentatively milestoned this pull request forv8.0.0
and opened it as a draft (only because of the milestone). Previous behavior regarding deprecated units can be ensured in a backwards-compatible way by settingparse_strict="warn"
explicitly because deprecated units will ignoreparse_strict
in olderastropy
.This only affects
"vounit"
and"ogip"
because the other formats don't have any deprecated units.This pull request closes #18532 even if we decide that the change is too breaking, but in that case the issue should be closed with the
wont-fix
label.