[ty] Retain the function-like-ness of Callable types when binding self

[AlexWaygood]

Summary

For something like this:

from typing import Callable

def my_lossy_decorator(fn: Callable[..., int]) -> Callable[..., int]:
    return fn

class MyClass:
    @my_lossy_decorator
    def method(self) -> int:
        return 42

we will currently infer the type of MyClass.method as a function-like Callable, but we will infer the type of MyClass().method as a Callable that is not function-like. That's because a CallableType currently "forgets" whether it was function-like or not during the bound_self transformation:

ruff/crates/ty_python_semantic/src/types.rs

Lines 10985 to 10987 in a57e291

	pub(crate) fn bind_self(self, db: &'db dyn Db) -> CallableType<'db> {
	CallableType::new(db, self.signatures(db).bind_self(db, None), false)
	}

This seems incorrect, and it's quite different to what we do when binding the self parameter of FunctionLiteral types: BoundMethod types are all seen as subtypes of function-like Callable supertypes -- here's BoundMethodType::into_callable_type:

ruff/crates/ty_python_semantic/src/types.rs

Lines 10844 to 10860 in a57e291

	#[salsa::tracked(cycle_initial=into_callable_type_cycle_initial, heap_size=ruff_memory_usage::heap_size)]
	pub(crate) fn into_callable_type(self, db: &'db dyn Db) -> CallableType<'db> {
	let function = self.function(db);
	let self_instance = self.typing_self_type(db);
	CallableType::new(
	db,
	CallableSignature::from_overloads(
	function
	.signature(db)
	.overloads
	.iter()
	.map(|signature| signature.bind_self(db, Some(self_instance))),
	),
	true,
	)
	}

The bug here is also causing lots of false positives in the ecosystem report on #21611: a decorated method on a subclass is currently not seen as validly overriding an undecorated method with the same signature on a superclass, because the undecorated superclass method is seen as function-like after binding self whereas the decorated subclass method is not.

Fixing the bug required adding a new API in protocol_class.rs, because it turns out that for our purposes in protocol subtyping/assignability, we really do want a callable type to forget its function-like-ness when binding self.

I initially tried out this change without changing anything in protocol_class.rs. However, it resulted in many ecosystem false positives and new false positives on the typing conformance test suite. This is because it would mean that no protocol with a __call__ method would ever be seen as a subtype of a Callable type, since the __call__ method on the protocol would be seen as being function-like whereas the Callable type would not be seen as function-like.

Test Plan

Added an mdtest that fails on main

[astral-sh-bot]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[astral-sh-bot]

mypy_primer results

Changes were detected when running on open source projects

antidote (https://github.com/Finistere/antidote)
- src/antidote/core/_raw/wrapper.py:102:13: error[unresolved-attribute] Object of type `(...) -> object` has no attribute `__get__`
- src/antidote/core/_raw/wrapper.py:136:13: error[unresolved-attribute] Object of type `(...) -> Awaitable[object]` has no attribute `__get__`
+ src/antidote/core/_raw/wrapper.py:102:13: warning[possibly-missing-attribute] Attribute `__get__` may be missing on object of type `((...) -> object) | ((...) -> object)`
+ src/antidote/core/_raw/wrapper.py:136:13: warning[possibly-missing-attribute] Attribute `__get__` may be missing on object of type `((...) -> Awaitable[object]) | ((...) -> Awaitable[object])`

dd-trace-py (https://github.com/DataDog/dd-trace-py)
- tests/debugging/probe/test_remoteconfig.py:69:9: error[invalid-assignment] Object of type `(...) -> Iterable[Probe]` is not assignable to attribute `get_probes` of type `(...) -> Iterable[Probe]`
- Found 8243 diagnostics
+ Found 8242 diagnostics

egglog-python (https://github.com/egraphs-good/egglog-python)
- python/egglog/runtime.py:745:9: error[invalid-assignment] Object of type `(() -> Declarations) | Unknown` is not assignable to attribute `__egg_decls_thunk__` of type `() -> Declarations`
- Found 1493 diagnostics
+ Found 1492 diagnostics

No memory usage changes detected ✅

[astral-sh-bot]

ecosystem-analyzer results

Lint rule	Added	Removed	Changed
invalid-assignment	0	2	0
possibly-missing-attribute	2	0	0
unresolved-attribute	0	2	0
Total	2	4	0

Full report with detailed diff (timing results)

[AlexWaygood]

The ecosystem diff shows two false-positive diagnostics going away. It also shows two pre-existing diagnostics becoming slightly more confusing due to the fact that we don't have a great way of distinguishing between function-like callables and non-function-like callables in our Type display yet.

[sharkdp]

Thank you!