call-non-callable in not TYPE_CHECKING scope only on Python 3.14

[dlech]

Summary

Here is a weird one...

I'm seeing a call-non-callable error in a block of code where TYPE_CHECKING is false. I would expect it to not be type checked because of that. And to make it more interesting, it only happens for Python 3.14. I don't see the error on earlier Python versions.

Reproduction: https://play.ty.dev/2e342426-a7a2-4629-a433-b2afea7a5b1c

Version

0.0.18

[dhruvmanila]

Thanks for the report!

I think that's an expected behavior because the type of completion is an instance of objc_block which doesn't have the __call__ method implemented. If you meant to say that the type of completion is the class objc_block itself then it should be annotated as completion: type[objc_block].

Now, it does seem weird because it seems to only be reproducing on 3.14 and not any other Python version. It does reproduce consistently when it's outside the conditional block in a standalone function:

def foo(name: objc_id, completion: objc_block):
    # This always gives me `call-non-callable` regardless of the Python version
    completion(name)

[dhruvmanila]

(cc @sharkdp regarding whether this is an issue related to dead code analysis)

Edit: It might be related to deferred annotations that got added to 3.14

[dlech]

I think that's an expected behavior because the type of completion is an instance of objc_block which doesn't have the __call__ method implemented.

Yes, that is why it is intentionally being requested to not be type checked. Since it should be dead code as far as type checkers are concerned, I would not expect the error though.

A bit more background, I found this while using a library that uses annotations for something other than type checking, so it has annotations with types that are not actually correct as far as type checkers go. But the "wrong" types are required because they are parsed at runtime to implement dynamic things behind the scenes.

[dhruvmanila]

Thanks for the context, curious to know which library that is if it's public.

[dlech]

It's https://rubicon-objc.beeware.org/en/stable/.

[sharkdp]

That's interesting. Thank you for reporting this.

A more minimal reproduction is this:

class NonCallable:
    pass

if False:

    def _(non_callable: NonCallable):
        non_callable()

https://play.ty.dev/e66893fb-688d-4a10-b14f-3ee8d2e315ef

I'm pretty sure the reason why 3.14 is relevant here is the deferred evaluation of annotations (Edit: oh, Dhruv also figured that out above). Before 3.14, we would look up NonCallable in the non_callable: NonCallable parameter definition through the if False statement and infer Unknown, which would not lead to any diagnostic (but I'm a bit confused why it's not Never). On 3.14+, we somehow resolve NonCallable to the actual <class 'NonCallable'> type, which leads to the error.

[carljm]

On 3.14+, we somehow resolve NonCallable to the actual <class 'NonCallable'> type, which leads to the error.

It's because we resolve it from the perspective of end-of-scope. At which location, of course, class NonCallable: pass is perfectly visible.