Python types have an expectations problem

Re:Python types have an expectations problem by hermitdev on Monday January 29, 2024 @11:29AM (#39178245)

In practice, this would be solved with `typing.overload`[0].

Using you example:

    from typing import overload
 
    @overload
    def fooify(x: int) -> int:
      ...
 
    @overload
    def fooify(x: list[int]) -> list[int]:
      ...
 
 
    def fooify(x: list[int] | int) -> list[int] | int:
      if isinstance(x, list):
        return [fooify(_x) for _x in x]
      return x * 2

[0] https://docs.python.org/3/library/typing.html#overload

[ Parent | on HN ]

Re:Python types have an expectations problem by olejorgenb on Monday January 29, 2024 @12:27PM (#39179144)

Or a bound typevar:

    T = TypeVar("T", bound=int | list[int])

    def(x: T) -> T:

[ Parent | on HN ]

Re:Python types have an expectations problem by nerdponx on Monday January 29, 2024 @05:41PM (#39183791)

And for an example of the practical limits of @overload, take a look at the Pandas type hints: https://github.com/pandas-dev/pandas/blob/dc5586baa9e4731805...

Meanwhile it's not even possible to express such things in other static type systems. So I'm not exactly an unhappy customer, but it does put certain things tantalizingly close, but still out of reach without a ton of clunky boilerplate and LoC explosion.

[ Parent | on HN ]

Re:Python types have an expectations problem by gpderetta on Tuesday January 30, 2024 @09:54AM (#39190746)

> it's not even possible to express such things in other static type systems

what do you mean? It seems relatively straightforward.

[ Parent | on HN ]