Pyrefly vs. Ty: Comparing Python's two new Rust-based type checkers

Post by sevensor » Wed, May 28, 2025, 3:56 PM UTC

notatallshaw wrote: post #142

mjr00 wrote: post #92

Earlier quoted context omitted.

> Following the general stupidness of the post: they are now unable to do that because a security consultant said they have to enable and can not break RUFF rule ANN401: https://docs.astral.sh/ruff/rules/any-type/ Okay, then your function which is extremely generic and needs to support 25 different use cases needs to have an insane type definition which covers all 25 use cases. This isn't an indictment of the type sy…

> Don't write functions that support hundreds of input data types But by it's nature, duck typing supports an unbounded number of input types and is what Python was built on. You've already decided duck typing is wrong and strict type adherence is correct, which is fine, but that doesn't fit the vast history of Python code, or in fact many of the core Python libraries.

Post by sevensor » Wed, May 28, 2025, 7:19 PM UTC

the_af wrote: post #110

notatallshaw wrote: post #87

Earlier quoted context omitted.

As the author of that post, I'd like to point out the example was meant to be stupid. The purpose was to show different ideologies and expectations on the same code don't work, such as strict backwards compatibilities, duck typing, and strictly following linting or type hinting rules (due to some arbitrary enforcement). Although re-reading it now I wish I'd spent more than an evening working on it, it's full of issue…

But there was a conceivable way (maybe not in Python) to make a `slow_add` function very generic, yet only be defined over structures where any conceivable `+` operation is defined. You just have to say the type implements Semigroup. Yes, this would work if the arguments are lists, or integers, or strings. And it won't pass the typecheck for arguments that are not Semigroups. It may not work with Python, but only bec…

    from dataclasses import dataclass
    from typing import Protocol, Self, TypeVar

    class Semigroup(Protocol):
        def __add__(self, other: Self) -> Self:
            ...

    T = TypeVar("T", bound=Semigroup)
    def join_stuff(first: T, *rest: T) -> T:
        accum = first
        for x in rest:
            accum += x
        return accum

    @dataclass
    class C:
        x: int

    @dataclass
    class D:
        x: int
        def __add__(self, other: Self) -> Self:
            return type(self)(self.x + other.x)

    @dataclass
    class E:
        x: int
        def __add__(self, other: Self) -> Self:
            return type(self)(self.x + other.x)

    _: type[Semigroup] = D
    _ = E

    def doit() -> None:
        print(join_stuff(1,2,3))
        print(join_stuff((1,), tuple(), (2,)))
        print(join_stuff("a", "b", "c"))
        print(join_stuff(D(1), D(2)))
        print(join_stuff(D(1), 3))
        print(D(1) + 3) # caught by mypy
        print(D(1) + E(3)) # caught by mypy
        print(join_stuff(1,2,"a")) # Not caught by mypy
        print(join_stuff(C(1), C(2))) # caught by mypy
    doit()

Post by josevalim » Wed, May 28, 2025, 9:06 PM UTC

HelloNurse wrote: post #147

josevalim wrote: post #54

Earlier quoted context omitted.

> Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. That depends on the implementation of gradual typing. Elixir implements gradual set-theoretic types where dynamic types are a range of existing types and can be refined for typing violations. Here is a trivial example: def example(x) do {Integer.to_string(x), Atom.to_string(x)} end Since the func…

How is this function definition (or maybe just its parameter x) "untyped"? There is enough information to deduce that the type of parameter x is empty and the type of the function doesn't matter because there is an error. If the body of the function contained only the first or the second call, the verdict would have been that x is respectively an Integer or an Atom and the type of the function is the type of the cont…

Post by maleldil » Wed, May 28, 2025, 9:28 PM UTC

vintagedave wrote: post #73

maleldil wrote: post #46

Earlier quoted context omitted.

beartype is great, but I only find it useful at the edges. Runtime checks aren't needed if you have strict typing throughout the project. On a gradually-typed codebase, you can use beartype (e.g. is_bearable) to ensure the data you're ingesting has the proper type. I usually use it when I'm dealing with JSON types.

Why isn’t it necessary? Do you mean that with edit-time type checking, you can catch all errors, so no need for runtime verification the edit-time type decls match? What about interacting with other libraries?

Post by jononor » Thu, May 29, 2025, 7:48 AM UTC

notatallshaw wrote: post #142

mjr00 wrote: post #92

Earlier quoted context omitted.

> Following the general stupidness of the post: they are now unable to do that because a security consultant said they have to enable and can not break RUFF rule ANN401: https://docs.astral.sh/ruff/rules/any-type/ Okay, then your function which is extremely generic and needs to support 25 different use cases needs to have an insane type definition which covers all 25 use cases. This isn't an indictment of the type sy…

> Don't write functions that support hundreds of input data types But by it's nature, duck typing supports an unbounded number of input types and is what Python was built on. You've already decided duck typing is wrong and strict type adherence is correct, which is fine, but that doesn't fit the vast history of Python code, or in fact many of the core Python libraries.