Skip to content
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

chore(issues): Simple type improvements #70697

Merged
merged 15 commits into from
May 13, 2024
Merged

Conversation

mrduncan
Copy link
Member

@mrduncan mrduncan commented May 10, 2024

Another quick batch of followups to #69828.

For review, no cross-file changes so each one is independently reviewable (aside from pyproject of course). Also, there are a handful in here which are not comprehensive - this intent of this PR is just to chip away at some easy improvements even if they're not yet enough to fully opt a module in quite yet.

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label May 10, 2024
self, group: Group, forecast_values=list[int], date_added=datetime
self, group: Group, forecast_values: list[int], date_added: datetime
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the only non-typing change, no actual effect since defaults are never used and they clearly would have been broken if they were.

Copy link

codecov bot commented May 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.03%. Comparing base (5a883ee) to head (4820d6d).
Report is 6 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #70697      +/-   ##
==========================================
- Coverage   80.04%   80.03%   -0.01%     
==========================================
  Files        6505     6505              
  Lines      290739   290742       +3     
  Branches    50102    50102              
==========================================
- Hits       232709   232703       -6     
- Misses      57593    57602       +9     
  Partials      437      437              
Files Coverage Δ
src/sentry/issues/attributes.py 84.47% <100.00%> (ø)
...entry/issues/endpoints/organization_group_index.py 92.89% <100.00%> (ø)
...c/sentry/issues/endpoints/organization_searches.py 95.12% <100.00%> (+0.12%) ⬆️
src/sentry/issues/endpoints/source_map_debug.py 98.03% <100.00%> (ø)
src/sentry/issues/escalating.py 93.66% <ø> (ø)

... and 8 files with indirect coverage changes

@mrduncan mrduncan marked this pull request as ready for review May 10, 2024 23:32
@mrduncan mrduncan requested review from a team as code owners May 10, 2024 23:32
Comment on lines -23 to +26
def process_occurrence_group_with_shutdown(*args, **kwargs):
process_occurrence_group(*args, **kwargs)
def process_occurrence_group_with_shutdown(items: list[Mapping[str, Any]]) -> None:
process_occurrence_group(items)
Copy link
Member

Choose a reason for hiding this comment

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

Feels like only **kwargs can be replaced by the list[Mapping[str, Any]] type and *args? cannot since there's no keywords? Or is there some Python/mypy magic happening behind the scenes that makes this okay?

Copy link
Member

Choose a reason for hiding this comment

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

**kwargs could have only been passed as items=... before as the underlying signature of process_occurrence_group is (list[Mapping[str, Any]]) -> None -- so this just makes the signature match explicitly

with *args, **kwargs mypy infers that as "this is a callable that could take any number of positional or named arguments" -- now it's explicitly "one possibly-named argument possibly positional argument named items of type ..."

Copy link
Member

@MichaelSun48 MichaelSun48 left a comment

Choose a reason for hiding this comment

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

lgtm! assuming there's some magic going on in test_run.py that I'm not aware of which is probably the case

If only mypy could automatically assume a function's return type was None if its not explicit 😢

Copy link
Member

@asottile-sentry asottile-sentry left a comment

Choose a reason for hiding this comment

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

@mrduncan mrduncan merged commit dfce1cf into master May 13, 2024
51 checks passed
@mrduncan mrduncan deleted the mrduncan/small-type-fixes branch May 13, 2024 16:26
@github-actions github-actions bot locked and limited conversation to collaborators May 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Backend Automatically applied to PRs that change backend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants