Added initial typehints#494
Conversation
# Conflicts: # rollbar/contrib/django/middleware.py # rollbar/test/test_rollbar.py
# Conflicts: # .github/workflows/ci.yml # pyproject.toml
|
@claude review |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
@codex please review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a8102b7dca
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
terencehonles
left a comment
terencehonles
left a comment
There was a problem hiding this comment.
This looks pretty extensive so that's nice to see. I see a couple things that you may want to consider.
You may want to consistently use from __future__ import annotations across the code. This does change the meaning of the imports at runtime and will require a consumer to resolve them differently, but since you didn't actually export the type comments I think this is a safe change to make and it makes sense to make it everywhere before you do export the type comments.
You're missing the py.typed marker, and you may want to add that. I'm not sure if you're waiting for more complete type coverage to export it.
You may want to lean into from __future__ import annotations by using modern syntax where not in a runtime position. I commented on a few of these and you can use a tool like pyupgrade to migrate these automatically, but it will change more than just the type definitions.
| return DEFAULT | ||
|
|
||
| # The keys will be coming from data objects in the payload, so they could be just about anything hashable. | ||
| KeyType = Union[str, int, float, binary_type, Hashable] |
There was a problem hiding this comment.
If you're using from __future__ import annotations does it make sense to just use the newer shorthand syntax:
| KeyType = Union[str, int, float, binary_type, Hashable] | |
| KeyType = str | int | float | binary_type | Hashable |
| allowed_circular_reference_types: Optional[type | tuple[type, ...]] = None, | ||
| memo: Optional[dict[int, tuple[KeyType, ...]]] = None, |
There was a problem hiding this comment.
If you're using from __future__ import annotations does it make sense to just use the newer shorthand syntax:
| allowed_circular_reference_types: Optional[type | tuple[type, ...]] = None, | |
| memo: Optional[dict[int, tuple[KeyType, ...]]] = None, | |
| allowed_circular_reference_types: type | tuple[type, ...] | None = None, | |
| memo: dict[int, tuple[KeyType, ...]] | None = None, |
|
|
||
| def transform(obj, transforms, key=None, batch_transforms=False): | ||
| class Handlers(TypedDict, total=False): | ||
| string_handler: Callable |
There was a problem hiding this comment.
These are all Callable[[Any, Any | None], Any] right? It might make sense to at least type this so that handlers have the right signature (via a typevar HandlerType would allow deduplication).
3 participants
Description of the change
This PR adds the initial work of getting static type checking with mypy working. Because we support Python 3.9 to 3.14 and have integrations with a lot of frameworks that may or may not exist in the environment, our type imports can be a little messy at times. As much as possible we try not to ignore types.
Type of change
Related issues
Checklists
Development
Code review