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

Opt-in error for if x: when x: None | int or None | str etc. #17892

Open
huonw opened this issue Oct 7, 2024 · 1 comment · May be fixed by #17893
Open

Opt-in error for if x: when x: None | int or None | str etc. #17892

huonw opened this issue Oct 7, 2024 · 1 comment · May be fixed by #17893
Labels

Comments

@huonw
Copy link

huonw commented Oct 7, 2024

Feature

The bug function below has a bug: the else branch will execute both when x is None and when it is empty, and the latter is unexpected. The programmer was hoping "" would be handled by the if branch.

It'd be handy if Mypy could (optionally) flag this sort of mistake, to help reminder the programmer that they probably should write something like fixed, i.e. take optional values like None | str as expressing intent that "" should behave differently to None.

def bug(x: None | str):
    if x: # error: None and str
        print(f"the str value is {x}") 
    else:
        print("the value is None")

def fixed(x: None | int):
    if x is not None: # no error
        print(f"the int value is {x}") 
    else:
        print("the value is None")

This also applies to:

  • built-ins like bool, float, int, list, dict, set (etc)
  • any "truthy" types, that implement __bool__ or __len__
  • arguably, type variables that could be substituted with any of those types (e.g. def bug[T](x: None | T) called like bug(""))

Pitch

It's very easy to write if x: out of habit when handling strings, lists and any other type with falsey values. When None is involved, this can lead to unexpected behaviour, where the falsey values like [], 0, "", {} are handled like None.

Mypy is very well positioned to catch this mistake given it has full type info (and indeed linters without full type info cannot do so).

This is likely to have some false-positives, and so should be optional. It feels conceptually similar, to me, to truthy-bool.

I've sketched an incomplete implementation in #17893, that I can complete with agreement/guidance.

@wyattscarpenter
Copy link
Contributor

wyattscarpenter commented Oct 9, 2024

Seems related to #16734, "Enforce [that] conditional values are booleans" ; although the idea of that issue is that every x in if x should actually have the type of bool, whereas your idea is (basically) that it's fine to use truthiness, just not if the type of x is a union with none (ie, an optional). Both ideas make sense to me as checks one might reasonably want to have.

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

Successfully merging a pull request may close this issue.

2 participants