Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

eerovaher
Copy link
Member

Description

The astropy unit parsing machinery recognizes and emits warnings about deprecated units, but (as reported in #18532) these warnings do not obey parse_strict. Making deprecated units obey parse_strict is not very complicated technically, but because by default parse_strict="raise" then astropy can start raising errors where it previously succeeded (with warnings). Because of this backwards-incompatible change I have tentatively milestoned this pull request for v8.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 setting parse_strict="warn" explicitly because deprecated units will ignore parse_strict in older astropy.

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.

  • By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

The updated tests demonstrate that parsing deprecated units with
`u.Unit(..., parse_strict=...)` ignores the `parse_strict` argument.
Copy link
Contributor

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.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

Copy link
Contributor

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

@@ -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")],
Copy link
Member Author

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",
Copy link
Member Author

@eerovaher eerovaher Aug 20, 2025

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.

Copy link
Contributor

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.
@eerovaher eerovaher force-pushed the deprecated-unit-parse-strict branch from 508ea6f to d829da9 Compare August 20, 2025 19:40
Copy link
Member

@nstarman nstarman left a 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.

@nstarman
Copy link
Member

We don't have a good mechanism to keep PRs updated if they aren't going into the current release...

Copy link
Contributor

@mhvk mhvk left a 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",
Copy link
Contributor

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: vounit parsing ignores parse_strict choice
3 participants