Can TypeVar defaults be used to inform Pyright in cases where an argument isn't provided?

[max-muoto]

One thing I was curious about with the new 3.13 type var defaults, is if they could be used to inform the type-checker in the case of an argument that might not be provided:

T = TypeVar("T", bound=str, default=str)

def foo(arg_1: int, *, arg_2: T = ...) -> T: ...

Playground

Currently this raises a warning, but I wasn't sure based on the language of PEP 696 if this has to be the case.

In generic functions, type checkers may use a type parameter’s default when the type parameter cannot be solved to anything. We leave the semantics of this usage unspecified, as ensuring the default is returned in every code path where the type parameter can go unsolved may be too hard to implement. Type checkers are free to either disallow this case or experiment with implementing support.

I feel this gives Pyright flexibility to support this case if it wants. Personally, I think there are a few situations where this helpful, or at least running into one right now.

[max-muoto]

For context, this is the behavior in MyPy. MyPy playground.

[max-muoto]

As for why I wouldn't just set a default in the stubs, I'm making some changes to stubs in the typeshed, and they have some linting rules to only allow "simple" defaults.

[max-muoto]

The PR if you're curious: python/typeshed#12104

[max-muoto]

@erictraut Just wanted to follow up here. Is there possibility of cutting an exception in the case of stubs?

[erictraut]

No, even if this behavior were sound from a type checking standpoint (which it isn't), there would be no justification for special-casing stubs in this case.

[max-muoto]

No, even if this behavior were sound from a type checking standpoint (which it isn't), there would be no justification for special-casing stubs in this case.

Sounds good!