Add reference implementation of PEP 718

[ilevkivskyi]

I think this is very much needed PEP, and using mypy for reference implementation is a good idea because mypy actually already (mostly) supports this under the hood.

The only non-trivial question is whether we should allow type applications only to references that are statically known to refer to a function, or do we want to support type application to an arbitrary expression that happen to have a callable-like type inferred? For example:

T = TypeVar("T")

class Callbacks(TypedDict):
    regular: Callable[[int], int]
    generic: Callable[[T], T]

def test(cb: Callbacks) -> None:
    cb["generic"][int]  # <- should we support this?

If we only want to support static references, then implementation is trivial, essentially:

• Make this error conditional on Python version <3.15 and file being not a stub.
• Update this helper to accept a Decorator.

However, if we want to support arbitrary expressions, it should be quite easy as well. Luckily, all the necessary infrastructure was added for TypeForm PEP support. We can use TypeCheckerAsSemanticAnalyzer adapter to re-interpret arbitrary expression as type during type checking.

cc @JukkaL @Gobot1234 @PabloRuizCuevas

[ilevkivskyi]

@PabloRuizCuevas found another thing: overload filtering. It is not needed for type application to type objects, but will be needed for the PEP. Unless I am missing something this should be easy, simply skip those overload that currently error-out (and error if the final list is empty).

[gvanrossum]

I didn't realize this issue already existed. I have a prototype (vibe-coded with Fable) in my branch: https://github.com/gvanrossum/mypy/tree/pep718

Do you want a draft PR?

UPDATE: The Discourse discussion is now focused on the exact problem Ivan highlighted. Fable chose to allow any Callable to be subscripted. Maybe I should see if it can instead only allow it for statically known generic functions? FWIW the branch seems to solve overload resolution as you suggest. But I don't understand mypy internals anymore (:-), so I'd like some review.

[ilevkivskyi]

@gvanrossum

Do you want a draft PR?

Yes, please go ahead! I may not have time for a review next one-two weeks as I am working on various new parser fixes for 2.4 release, but someone else may have time to take a look. Also it is easier to comment/discuss a PR rather than a fork.

Maybe I should see if it can instead only allow it for statically known generic functions?

FWIW I don't have a strong opinion either way, as both ways have some pros and cons. I am curious to see what other people think about this.

[JukkaL]

FWIW I don't have a strong opinion either way, as both ways have some pros and cons. I am curious to see what other people think about this.

I don't see a good reason to allow type application to be used with non-generic functions -- mypy can't do anything with the type application, so it seems like it would be a source of confusion:

def my_func(x: str) -> str: ...

...

# This should probably generate an error
print(my_func[int]('x'))  # What's the purpose of 'int' here?

This would be consistent with the way we don't allow this with non-generic classes:

class Foo: pass

x: Foo[int]  # Error: "Foo" expects no type arguments

[ilevkivskyi]

@JukkaL the question is not about whether to allow this (obviously non-sense) situation, but about whether to allow applying type arguments to an arbitrary expression that has a generic callable type (see my original example) vs only the "static" references to generic functions (like we do currently for generic classes).

[JukkaL]

Ah yes that one is a trickier case. I think to avoid false positives, I'd lean towards allowing this, since values with callable types come up in many contexts, and the vast majority of callable values are actually "ordinary" function objects.

We already allow accessing the __name__ attribute with an arbitrary callable, even though a user-defined class with __call__ doesn't generally have this, for example. This seems like a conceptually similar case where we introduce some unsafety to avoid false positives.

However, if many callable, non-function objects in the stdlib still don't allow indexing, we might want to restrict this.

Another random idea would be to require __getitem__ along with __call__ for an object to be considered a generic callable, but this may well be problematic.