Replace : Incomplete | None = None with =None? #14029
Description
From #14027
The form Incomplete | None = None is basically a holdover from before we included defaults in stubs, where Incomplete | None = ... provided extra information.
This is still interpreted as Any | None by mypy. And now more correctly interpreted as Unknown | None by pyright.
Unknown | None instead of Any | None sounds like this would be worth it alone. I also like that this form would be more succinct, while being quite obvious.
@Avasam also wrote:
Some stubs might also use it in select places specifically to pass pyrightconfig.stricter.json
This is something we need to look out for, but is - in my opinion - not a valid reason not to do this. Marking something as "strict" when it's using Incomplete is cheating anyway, and we don't allow bare Incomplete statements.
Whatever we decide, we should enforce the style using flake8-pyi.
If we change this, we should also ask mypy to change stubgen to follow this style.
Activity
Replace `Incomplete | None = None` in third party stubs
consider default value when inferring param type
lev-blit commented on Oct 13, 2025
This causes conflict with pyright strict mode, specifically reportUnknownParameterType (which probably comes together with reportMissingParameterType)
srittau commented on Oct 13, 2025
That's fine and expected. pyright not reporting reportMissingParameterType is actually a bit of an unintended side-effect of using Incomplete.
lev-blit commented on Oct 14, 2025
So packages which have incomplete with default None should be excluded from the stricter pyright?
Seems like at some point we'd also like to check if there are packages who are "strict capable" (all parameters typed) and remove them from the exclusion
AlexWaygood commented on Oct 14, 2025
It's obviously not an ideal end state for any typeshed package to be incomplete. We welcome PRs to improve our stubs, if missing type annotations are causing issues for you when you enable pyright's strict mode!
AlexWaygood commented on Oct 14, 2025
It's not part of typeshed's CI, but I do get an issue like this over at typeshed-stats if a package is "strict-ready" but is not tested with pyright's strict mode in typeshed's CI: AlexWaygood/typeshed-stats#369. So we're pretty good at keeping the list of packages excluded from pyright's strict mode in our CI to a minimum.
We could fairly easily run that check in typeshed's CI if we added typeshed-stats as a test dependency.
srittau commented on Oct 14, 2025
Related: #14052