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

Types for "truthy" and "falsy" values #1606

Open
Feuermurmel opened this issue Jan 24, 2024 · 7 comments
Open

Types for "truthy" and "falsy" values #1606

Feuermurmel opened this issue Jan 24, 2024 · 7 comments
Labels
topic: feature Discussions about new features for Python's type annotations

Comments

@Feuermurmel
Copy link

I found this function in our codebase and I'm trying to type it:

def run_until_truthy(fn, num_tries=5):
    for _ in range(num_tries):
        if res := fn():
            return res

    Exception('Giving up.')

The function repeatedly calls a callable without arguments until it returns a "truthy" value. Then it returns that value. Easy enough:

T = TypeVar("T")

def run_until_truthy(fn: Callable[[], T], num_tries: int = 5) -> T: ...

This is correct but too restrictive. Usages like this don't work:

def test() -> None:
    def load_something() -> str | None:
        pass

    # mypy: Incompatible types in assignment (expression has type "str | None", variable has type "str")
    something: str = run_until_truthy(load_something)

I can hack it to make it work:

Falsy: TypeAlias = Literal[None, False, 0, "", b""] | tuple[()]

def run_until_truthy(fn: Callable[[], T | Falsy], num_tries: int = 5) -> T: ...

Does it make sense to add official Truthy and Falsy types to the standard library?

Maybe a Truthy type would also make sense. Truthy can't be defined as a type alias of existing types, but could probably also be useful sometimes, e.g. to type the following function:

def get_falsy_values(seq: list[T | Truthy]) -> list[T]:
    return [i for i in seq if not i]

From thinking about it for a few minutes, I think Falsy would be more often useful than Truthy, at least in combination with the current typing features.


If there's an intersection type constructor at some point, the above examples could be written like this instead, which might be easier to understand:

def run_until_truthy(fn: Callable[[], T], num_tries: int = 5) -> Intersection[T, Truthy]: ...
def get_falsy_values(seq: list[T]) -> list[Intersection[T, Falsy]]:
@Feuermurmel Feuermurmel added the topic: feature Discussions about new features for Python's type annotations label Jan 24, 2024
@JelleZijlstra
Copy link
Member

In typed code I would prefer checking explicitly for None instead of all falsy values:

def run_until_not_none[T](fn: Callable[[], T | None], num_tries: int = 5) -> T:
    for _ in range(num_tries):
        if (res := fn()) is not None:
            return res

    Exception('Giving up.')

This can already be typed and is less likely to lead to surprises.

@elenakrittik
Copy link

Would this work for your case?

@Feuermurmel
Copy link
Author

Would this work for your case?

I don't think addresses by use case. The type returned by run_until_truthy(foo) is still str | None, even though it will never return None: Playground

@Feuermurmel
Copy link
Author

In typed code I would prefer checking explicitly for None instead of all falsy values:

def run_until_not_none[T](fn: Callable[[], T | None], num_tries: int = 5) -> T:
    for _ in range(num_tries):
        if (res := fn()) is not None:
            return res

    Exception('Giving up.')

This can already be typed and is less likely to lead to surprises.

If I wrote that part of the application now, I would definitely use this approach. But I have found existing usages that make use of the fact that the function will be re-run on return values [] and "".

Another case where these types could be useful is when typing functions that have behavior similar to the and and or operators: Playground

@Daverball
Copy link
Contributor

Daverball commented Jan 26, 2024

from typing import Literal, Protocol

class Truthy(Protocol):
    def __bool__(self) -> Literal[True]: ...

class Falsy(Protocol):
    def __bool__(self) -> Literal[False]: ...

This doesn't really appear to work in pyright or mypy however, since None is special cased and doesn't actually follow the NoneType annotation for __bool__ on typeshed, for the others it doesn't work, since Literal[0, "", b"", False] aren't special cased to fulfil this Protocol.

But I would seriously question the value of making something like this work, since excluding a single literal from a type is usually not that helpful (Literal[True, False] are kind of the exception). I think excluding None is usually sufficient and will give you the result you want in most cases.

Of course you could write a couple of simple TypeGuards to convert any value into Truthy/Falsy, but that wouldn't be particularly ergonomic to use and doesn't help with the given example (but it may help with the and/or usecase)

@Feuermurmel
Copy link
Author

But I would seriously question the value of making something like this work, since excluding a single literal from a type is usually not that helpful (Literal[True, False] are kind of the exception). I think excluding None is usually sufficient and will give you the result you want in most cases.

Of course you could write a couple of simple TypeGuards to convert any value into Truthy/Falsy, but that wouldn't be particularly ergonomic to use and doesn't help with the given example (but it may help with the and/or usecase)

My request stems purely from typing existing code. Partly, that code is a result of how Python employs the concept of truthy/falsy in boolean contexts. Because of typing ergonomics, I usually refrain from relying on that concept (e.g. bar if foo is None else None rather than foo or bar), but the language is still pushing me in the direction of using these concepts and I see a lot of code being written that relies on it and is hard to type.

@finite-state-machine
Copy link

It may be helpful to note that object.__bool__() does not exist, which makes the link between if/bool() and __bool__() tenuous. (It might simplify the world if object.__bool__() was defined, and bool(x) was equivalent to x.__bool__(), subject to type checks.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: feature Discussions about new features for Python's type annotations
Projects
None yet
Development

No branches or pull requests

5 participants