httpx
httpx copied to clipboard
encode
Typing: add explicit types for public fields
Without these, type inference would be required, the output of which can differ between type checkers. Explict fields also serves as documentation and can be a place to add explicit field descriptions in future.
pyright reports: after.txt before.txt
So, I'm less convinced about this one...
- We don't have any tooling at the moment that prevents anything from regressing.
- It doesn't look consistent to me. The change is on
RequestandResponseandCookies, but there's several other classes that it could equally well apply too?
Personally my suggestion would be that we punt on any pyright based changes, until we've completed the mypy --strict config, by tackling the issues in #2436 one-by-one.
- We don't have any tooling at the moment that prevents anything from regressing.
That could be pyright --verifytypes.
- It doesn't look consistent to me. The change is on
RequestandResponseandCookies, but there's several other classes that it could equally well apply too?
pyright --verifytypes looks at the exported types and then only those entries that are ambiguous due to inference rules being inconsistent.
I was thinking about what sorts of changes can happen and what would get caught or not.
1. New field added to
A new parameter is added to __init__ that becomes a field. It's inferred correctly by mypy and we don't add it. Most users aren't impacted but these explicit fields slowly loose value as documentation.
2. Type of field changed in __init__
This would immediately be caught by mypy or any other type checker as soon as we try to assign to it.
3. Field deleted
This would not be caught by any type checker that I know of and if we don't access the attribute in tests we'd be shipping a bug (we promised it exists but doesn't).
If y'all are keen on having pyright pass cleanly, maybe we should start out with a discussion or issue similar to #2436, so we can make sure to tackle this fully.