Skip to content

Refactor GT.opt_all_caps()#436

Merged
rich-iannone merged 14 commits into
posit-dev:mainfrom
jrycw:update-opt-all-caps
Feb 13, 2026
Merged

Refactor GT.opt_all_caps()#436
rich-iannone merged 14 commits into
posit-dev:mainfrom
jrycw:update-opt-all-caps

Conversation

@jrycw
Copy link
Copy Markdown
Collaborator

@jrycw jrycw commented Sep 11, 2024

I'm curious if GT.opt_all_caps() can be refactored as suggested in this PR.

@codecov
Copy link
Copy Markdown

codecov Bot commented Sep 11, 2024

Codecov Report

❌ Patch coverage is 92.30769% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.31%. Comparing base (06e6b6d) to head (4ae6ea7).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
great_tables/_options.py 92.30% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #436      +/-   ##
==========================================
- Coverage   92.35%   92.31%   -0.04%     
==========================================
  Files          48       48              
  Lines        6040     6039       -1     
==========================================
- Hits         5578     5575       -3     
- Misses        462      464       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jrycw jrycw force-pushed the update-opt-all-caps branch 2 times, most recently from b1197c4 to d932df5 Compare September 12, 2024 10:41
@jrycw jrycw force-pushed the update-opt-all-caps branch from d932df5 to f0ae1a7 Compare September 12, 2024 11:07
@jrycw
Copy link
Copy Markdown
Collaborator Author

jrycw commented Sep 12, 2024

@rich-iannone and @machow , sorry for the messy commits.

The reason for this is that while trying to modify the locations parameter to favor Loc objects, a circular import issue occurred.

Currently, the type annotation and initial value of locations are incorrect, causing the documentation build to fail in CI. Since this is a breaking change, I would like to get your feedback on this proposed update.

@machow
Copy link
Copy Markdown
Collaborator

machow commented Sep 12, 2024

Hey, thanks for working on this -- this was a good nudge that we should probably circle back to #341 and round out the support of loc pieces in Great Tables. I can pick up #341 next week, so we can merge these changes in around the same time :).

@jrycw
Copy link
Copy Markdown
Collaborator Author

jrycw commented Sep 13, 2024

Thanks for bringing up the related issue. Initially, I was thinking of using a Loc object like loc.column_labels for the locations parameter. However, using a Loc instance like loc.column_labels() seems like a better idea.

@machow
Copy link
Copy Markdown
Collaborator

machow commented Oct 4, 2024

Sorry for the wait, now that the new location stuff is merged in, I can take a look at this next week

@rich-iannone rich-iannone requested a review from machow as a code owner February 13, 2026 01:49
@machow machow assigned machow and unassigned rich-iannone Feb 13, 2026
Copy link
Copy Markdown
Collaborator

@machow machow left a comment

Choose a reason for hiding this comment

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

This LGTM, I did a quick scan -- but based on our pairing feel good about it. I left a quick note about making a type more specific. Feel free to add here and merge, or punt on it!

Comment thread great_tables/_options.py Outdated
self: GTSelf,
all_caps: bool = True,
locations: str | list[str] = ["column_labels", "stub", "row_group"],
locations: type[Loc] | list[type[Loc]] | str | list[str] | None = None,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I wonder if type[Loc] could be more specific? Since some types of Loc can't be passed.

list[Literal[LocColumnLabels, LocRowGroups, LocStub]]

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.

Found that list[Literal[LocColumnLabels, LocRowGroups, LocStub]] won't work because Literal is for values like strings/ints, but this simimlar approach works:

type[LocColumnLabels] | type[LocRowGroups] | type[LocStub] | list[type[LocColumnLabels] | type[LocRowGroups] | type[LocStub]] | ...

Comment thread great_tables/_options.py
if invalid:
raise ValueError(f"Invalid location string: {invalid[0]!r}")
locations = [_str_to_loc[x] for x in locations]
warnings.warn(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Can you put the warning at the top of the if any(...), so people will see it whether or not this errors?

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.

Done!

@rich-iannone rich-iannone merged commit f657d81 into posit-dev:main Feb 13, 2026
13 of 14 checks passed
@jrycw jrycw deleted the update-opt-all-caps branch February 14, 2026 04:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants