Skip to content

Refactor units formats FITS and VOUNIT a bit more - #14437

Merged
mhvk merged 3 commits into
astropy:mainfrom
mhvk:units-format-refactor-a-bit-more
Feb 23, 2023
Merged

mhvk merged 3 commits into
astropy:mainfrom
mhvk:units-format-refactor-a-bit-more

Conversation

@mhvk

@mhvk mhvk commented Feb 22, 2023 •

Copy link
Copy Markdown
Contributor

This pull request follows up on #14416 to refactor also FITS and VOUNIT a bit more. Mostly, it was an oversight of not realizing that the sorting done in those formats was not actually necessary, as it just duplicated what is done already in their superclass, generic.

Note that on purpose this does not change the sorting -- which I think should be done but which changes a lot of tests, so needs separate discussion! (EDIT: see #14449)

EDIT: I added a commit that does not strictly belong, but I'm lazy: in the previous PRs, starting with #14393, we called the numerator of a fraction the nominator, which is incorrect (although apparently so common that Fraction.nominator exists and that none of the many reviewers noticed it...). Anyway, the last commit corrects it. EDIT: Fraction.nominator does not exists; apparently, that line in utils.py is never exercised...

mhvk added 2 commits February 22, 2023 15:54
This prepares it to be able to use in-line fractions as well.
@github-actions

github-actions Bot commented Feb 22, 2023 •

Copy link
Copy Markdown
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 "When to rebase and squash commits".
  • 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?
  • Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
  • 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.

@github-actions

Copy link
Copy Markdown
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?

@mhvk
mhvk marked this pull request as ready for review February 22, 2023 21:01
@nstarman

Copy link
Copy Markdown
Member

If the sorting isn't necessary, can we switch to tuples, re the last PR.

@mhvk

mhvk commented Feb 22, 2023

Copy link
Copy Markdown
Contributor Author

@nstarman - we could do the change to tuples if we also remove the sorting in generic -- remind me in #14439 if we decide to go with that...

@pllim

pllim commented Feb 22, 2023

Copy link
Copy Markdown
Member

a bit more... ?

@mhvk

mhvk commented Feb 22, 2023

Copy link
Copy Markdown
Contributor Author

A bit more than #14416 😺

@mhvk

mhvk commented Feb 23, 2023

Copy link
Copy Markdown
Contributor Author

I added a commit that does not strictly belong, but I'm lazy: in the previous PRs, starting with #14393, we called the numerator of a fraction the nominator, which is incorrect (although apparently so common that Fraction.nominator exists and that none of the many reviewers noticed it...). Anyway, the last commit corrects it.

@mhvk

mhvk commented Feb 23, 2023

Copy link
Copy Markdown
Contributor Author

Well, actually Fraction.nominator does not exist - apparently that line is never exercised (I think it can be...)

@olebole olebole left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the non-blocking question about formats for FITS and VOUNIT, I son't have further issues.

return super().format_exponential_notation(val, format_spec)

@classmethod
def to_string(cls, unit, inline=True):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should machine readable output formats have options like inline here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, you are right, one can never have a "non-inline" format for FITS and VOUNIT. In a way, this is kind of a placeholder for a change to fraction in #14449 - I think FITS at least allows in-line fractions.

Since the same holds for cds where currently there is no check either (since it just inherits), how about we keep it here but ensure that in #14449 anything that is not allowed by the standard raises an error?

@nstarman

Copy link
Copy Markdown
Member

Just to make sure I'm getting this right. While this PR adds "inline" arguments in a few places, the long-term plan is to remove that argument in favor of the "fraction" argument? The "fraction" argument will be checked for correct input and e.g. error in VOUNIT if given a non-inline option.

@mhvk

mhvk commented Feb 23, 2023

Copy link
Copy Markdown
Contributor Author

@nstarman - indeed, this PR just completes the refactoring (mostly) without behaviour change started in #14417 (which in turn followed on what @olebole did in #14393), and then #14439 and #14449 make some real changes. Really, this PR should have been part of #14416...

@nstarman nstarman left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mhvk. In light of the future refactoring plan, this PR looks good to go.

@mhvk
mhvk merged commit d060cc6 into astropy:main Feb 23, 2023
@mhvk
mhvk deleted the units-format-refactor-a-bit-more branch February 23, 2023 20:56
Comment thread astropy/units/format/fits.py Resolved
Comment thread astropy/units/format/vounit.py Resolved
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.

4 participants