Skip to content

Conversation

@davidhalter
Copy link
Contributor

This latest update passes most conformance tests for Zuban. I simplified the flags for zuban check and it also passes 2 more tests for Pyrefly.

I have made several small changes to the tests. These should mostly be uncontroversial:

  • Made it possible to report unreachable after a function that returns Never.
  • Removed a redundant import that Zuban reported
  • A method can now be inferred as SelfTypeVar = TypeVar("SelfTypeVar", bound=Foo7[int]); Callable[[SelfTypevar], SelfTypeVar] instead of Callable[[Foo7[int]], Foo7[int]]. I personally believe this should be how we infer things, since it's more precise but I don't think we have to mandate this.
  • I allowed type checkers to return list[Any] instead of Any in an overload, if there was no match, because both of the overloads return a list and it is therefore just a slightly more precise type.
  • I added an additional optional error for taking a TypeVar of an outer generic class (in an __init__). There is already an error for the outer attribute x, but I feel like this error should be fine.

There remain 4 non-passing tests for Zuban, all of which I'm not sure the tests are doing the right thing. I will be discussing these in the typing discourse.

ret2 = example4(v2, 1)
assert_type(ret2, Any)
assert_type(ret2, Any) # E[example4]
assert_type(ret2, list[Any]) # E[example4]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't Step 5 of https://typing.python.org/en/latest/spec/overload.html#step-5 explicitly mandate Any (not list[Any]) here?

Copy link
Contributor Author

@davidhalter davidhalter Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, that it's written that way. My personal opinion is that it should be possible for type checkers to be more precise than what the spec mandates. I personally would also be supportive to allow list[int] | list[str], but I doubt any type checker would do that.

It's of course possible for me to disable this fallback logic, but I'd rather not, because I find it useful. I also don't think that it's necessary to explain in the spec that fallback types can be used. But if people don't think so, then I probably have to start a discussion about this as well (like 2-3 other cases where Zuban is more strict).

In this specific case I also doubt that it will cause interoperability issues, since anybody using the overload will work with a list output.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our motivation for standardizing the overload algorithm was to ensure that type checkers produce the same result when evaluating overloaded calls. Allowing variations would be run counter to this goal.

Copy link
Contributor Author

@davidhalter davidhalter Dec 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think that it's good that overloads are standardized. I'm just a bit sad that this behavior is being ditched for IMO no good reason. I have changed it regardless, I don't think it's worth discussing. I did not yet create a Zuban release, so you should probably not merge yet.

Are there other issues? Happy to create a release otherwise.

…luation"

Reverted because this change was not according to the spec.

This reverts commit 593d74d.
@@ -1,12 +1,9 @@
conformant = "Partial"
notes = """
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can remove the empty notes section (possibly in a few more files too)

return x
stop()
... # E?: This statement can be marked unreachable
return "whatever works" # No type error
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth I wouldn't mind allowing an error here; the type is clearly wrong and I don't think it's wrong for type checkers to detect that even in unreachable code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(No change requested though; fine to leave it as is.)

Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants