Skip to content

Feature requests: recognise that some types always evaluate to False #8692

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

Closed
reinhrst opened this issue Apr 17, 2020 · 4 comments
Closed

Feature requests: recognise that some types always evaluate to False #8692

reinhrst opened this issue Apr 17, 2020 · 4 comments
Labels

Comments

@reinhrst
Copy link

  • Are you reporting a bug, or opening a feature request?
    Feature Request
  • Please insert below the code you are checking with mypy,
import typing as t


class NotPresent:
    def __bool__(self) -> t.Literal[False]:
        return False


x: t.Union[NotPresent, t.Sequence[int]] = [1]
reveal_type(x)
if x:
    print(x[0])
  • What is the actual behavior/output?
    test.py:12:11: error: Value of type "Union[NotPresent, Sequence[int]]" is not indexable

  • What is the behavior/output you expect?
    The if x branch should recognise that x cannot be of type NotPresent (as it would do if it was None rather than NotPresent)

  • What are the versions of mypy and Python you are using?
    0.770 & master

  • What are the mypy flags you are using? (For example --strict-optional)
    None

@povilasb
Copy link

This is awesome.
A funny thing is that I posted exactly the same question on Stackoverflow yesterday :)

If I were to contribute some of my precious time, how would I approach this problem given I haven't worked with mypy source code?

@hauntsaninja
Copy link
Collaborator

Might need some discussion, since you could subclass NotPresent to do something else.

@reinhrst
Copy link
Author

I think that (rightly) mypy does not allow you to subclass NotPresent with a __bool__ method with a more permissive returntype than t.Literal[False], right?

@hauntsaninja
Copy link
Collaborator

Yup, you're right. I believe this is also fixed on master by #9297

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants