Default argument with incompatible type

Thanks for the quick and thoughtful responses.

On question 1, there appears to be a consensus that this should not be reported as an error at the call site and should not affect overload matching. The arguments made in favor of this viewpoint are compelling.

On question 2, it sounds like opinions are more mixed.

@Dr-Irv, to address your point… you can provide the real default value rather than .... This approach is preferable (even in type stubs) now that type information is used by millions of Python developers to power language server features. If the real default value is provided, editors can display additional relevant information to consumers of APIs.

I think Carl makes a good point on question 2. I’d likewise prefer not to extend the ellipsis special case beyond stubs.

As a next step, I’ll work on proposed wording for a typing spec update. Since this will involve a new section on call evaluation, I’ll probably also include wording for unpacked arguments based on this thread.

1 Like