Repository navigation
Refactor to_string in the unit formats - #14416
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.
|
|
👋 Thank you for your draft pull request! Do you know that you can use |
1a7936f to
de24d8c
Compare
|
For reviewers: it may help to look commit by commit - they are more or less logically organized... |
nstarman
left a comment
There was a problem hiding this comment.
I think when this PR was rebased it lost the explanatory comments, e.g. in def to_string(cls, unit, inline=False):
|
Oops! Will get those back! |
de24d8c to
03146c3
Compare
|
OK, those comments are back. While going through where exactly they were dropped, I noticed that I had also dropped useful comments in latex's description of why we typeset units like degrees differently when they are raised to a power. So, reinstated that too. |
nstarman
left a comment
There was a problem hiding this comment.
This PR looks good. My comments are minor and mostly focused on speed.
| return name | ||
|
|
||
| @classmethod | ||
| def _format_unit_list(cls, units): |
There was a problem hiding this comment.
I think a tuple will always work here. Perhaps this should be changed since tuples are faster and more memory efficient.
There was a problem hiding this comment.
Agreed. Did you think we should change the name? (I think better to leave it the same)
There was a problem hiding this comment.
It's private, so we're free to change it. And it's more explicit and will help when we add typing. I would be inclined to change the name.
There was a problem hiding this comment.
utils.grouped_by_powers does return lists for nominator and denominator (constructed by appending, so logical). So, _format_unit_tuple is incorrect.
Actually, looking at the override ingeneric - that does a .sort, so it does assume a list. Frankly, generic with inline=True looks awful, but that is for the next PR... For now, let me just revert those tuples to lists (and add a test...)
There was a problem hiding this comment.
SGTM. I suppose allowing lists, but using tuples wherever possible is good enough.
03146c3 to
9351845
Compare
|
CI failures seem unrelated (asdf in -dev) |
The fix is in #14429. |
olebole
left a comment
There was a problem hiding this comment.
I have no issues here, for me this all looks very nice and IMO make the unit formatting code much better to maintain. Thank you!
|
There is still an unchecked checkbox in the original post. So, is this PR ready now or still waiting for something else? |
9351845 to
ddcaac6
Compare
|
@pllim - I think all is ready now. Next PRs might actually change things... |
pllim
left a comment
There was a problem hiding this comment.
I don't grok the internals but changes to the expected test results LGTM, so I am approving by proxy. I'll let nstarman do a final review as well.
Thanks, everyone!
Are you sure? I don't see any failure. The red "x" is from -0.03% decrease. |
|
The one stuck is "CI / tests / Python 3.9 with all optional dependencies (MacOS X) (pull_request) " https://github.com/astropy/astropy/actions/runs/4245294951/jobs/7380620766 |
|
I reran the "failed" ones. That job does not do coverage. Not sure why it took so long though. |
|
Weird, as you can see from the log, it did try to upload to codecov, which is what got stuck. Anyway, happy it worked on a second go! |
|
I think this is a bug. It is trying to upload even when no coverage was computed: |
|
We use that OpenAstronomy template now in Actions, so I think I'll have to report this upstream. See OpenAstronomy/github-actions-workflows#109 |
|
Thanks! |
This pull request refactors the output in the
units.formatclasses, makingto_string()simpler.Right now there is no behaviour change except that the unused "unscaled" class is deprecated (removing a test for it that I had just added).
EDIT: this PR is too complex, and I decided to break it up in parts (leaving this
as draft to give a sense where it is going, and perhaps still use itfor the wrap-up):Baseand inheriting it.EDIT: possible follow-up:
inlinetofraction={False|'display'|'inline'}or something similar;