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

Any type causes worse type inference with higher-order function #11610

Open
JukkaL opened this issue Nov 24, 2021 · 0 comments
Open

Any type causes worse type inference with higher-order function #11610

JukkaL opened this issue Nov 24, 2021 · 0 comments
Labels
bug mypy got something wrong false-positive mypy gave an error on correct code

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 24, 2021

The first call to g generates an error, but the second one doesn't:

from typing import TypeVar, Callable, Iterable, Optional, List, Any

T = TypeVar("T")

def g(f: Callable[[T, T], T], seq: Iterable[Optional[T]]) -> Optional[T]: ...

a: List[Any]
# Incompatible types in assignment (expression has type "Optional[SupportsLessThanT]", variable has type "Optional[int]")
b: Optional[int] = g(min, a)  # Error!

a2: List[int]
b2: Optional[int] = g(min, a2)  # No error

The only difference between the cases is that the first one has a less precise type (List[Any] vs List[int]). Making a type less precise shouldn't generate more type errors, so this is arguably a bug. We should probably propagate the Any type from List[Any] to the return type.

@JukkaL JukkaL added bug mypy got something wrong false-positive mypy gave an error on correct code labels Nov 24, 2021
PIG208 added a commit to PIG208/zulip that referenced this issue Jul 22, 2022
Type inference does not work well when the default value of `REQ` is
non-optional while `ResultT` is optional. Mypy tries to unify
`json_validator` with `Validator[int]` in `invite_users_backend` instead
of the desired `Validator[Optional[int]]` because of the presence of the
default value `settings.INVITATION_LINK_VALIDITY_MINUTES`, which is
inferred to be an `int`. Mypy does not resort to a less precise type but
instead gives up early.

This issue applies to invite_users_backend and generate_multiuse_invite_backend
in zerver.views.invite.

There might be a way that we can add an overload to get around this, but
it's probably not worth the complexity until it comes up again more frequently.

We do in fact allow `invite_expires_in_minutes` to be `None` in places
like `do_invite_users`, `invite_users_backend`, etc, and we have
`settings.INVITATION_LINK_VALIDITY_MINUTES` as the default for them. So
it makes sense to allow having an optional value for this setting. And
since there isn't a way to independently set the value of this constant,
we move it to a different place.

TODO:

This is a temporary fix that should be refactored when the bug is fixed.

The encountered mypy issue: python/mypy#11610

Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong false-positive mypy gave an error on correct code
Projects
None yet
Development

No branches or pull requests

1 participant