Pyrefly doesn't recognise user-defined `all` function

[MarcoGorelli]

Describe the Bug

Pyrefly doesn't recognise user-defined all function

Sandbox Link

https://pyrefly.org/sandbox/?code=GYJw9gtgBALgngBwJYDsDmUkQWEMogCmAboQIYA2A%2BvAoQFD0DGFZAzm1AGJhgBc9KEKgATQsCjAAriiYAKNoQrAAlFAC0APigA5MCkIDhxgoRhSQKKJQpyVjMRJt2N2vQaPCi5y7v0N6IlJKGkRCOR4wOwA6aVk7eyA&version=3.12

(Only applicable for extension issues) IDE Information

No response

[grievejia]

I think this issue is similar to this one, as they share the same the underlying question: what to do when there's a naming conflict with builtins and it's unclear how the conflict can be resolved statically?

I don't it's generally possible to handle this kind of example perfectly. It is true that in your example:

from typing import reveal_type

class Foo:
    def func(self) -> None:
        return all()  # <- here `all` refers to the function defined below at runtime

def all() -> None:
    return None

reveal_type(Foo().func())

The invocation to all() refers to the customly-defined all() function. But if I simply swap the order between the reveal_type and all:

from typing import reveal_type

class Foo:
    def func(self) -> None:
        return all()  # <- here `all` refers to the function defined in Python builtin module

reveal_type(Foo().func())

def all() -> None:
    return None

There the invocation to all() refers to the builtin all() function. It's also not hard to imagine a case where which all is taken depends on a runtime value that's impossible to know statically:

from typing import reveal_type
from random import random

class Foo:
    def func(self) -> None:
        return all()

if random() > 0.5:
    def all() -> None:
        return None

reveal_type(Foo().func())

Currently Pyrefly treats the type of all() inside Foo.func() as a union of the two possibilities (i.e. Callable[[], None] | Callable[[Iterable], bool]) which actually correctly flags the issue where which all the original code is referring to is not "stable" and can change if blocks of code get moved around within the file.

I'm tempted to think that the current Pyrefly behavior is more desirable. But mypy/pyright both choose to do the wrong thing (i.e. unconditionally prioritize the custom all() over the builtin all) so I can also see an argument otherwise. Curious what other folks think.