Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[PEP 695] Fix incorrect Variance Computation with Polymorphic Methods.#19466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
randolf-scholz wants to merge3 commits intopython:master
base:master
Choose a base branch
Loading
fromrandolf-scholz:fix_variance_polymorphic_constructor

Conversation

randolf-scholz
Copy link
Contributor

@randolf-scholzrandolf-scholz commentedJul 16, 2025
edited
Loading

My idea for fixing it was to replacetyp = find_member(member, self_type, self_type) withtyp = find_member(member, self_type, plain_self) inside the functioninfer_variance, whereplain_self is the type of self without any type variables.

To be frank, I do not myself 100% understand why it works / if it is safe, but below is my best effort explanation.
Maybe a better solution is to substitute all function variables withUninhabitedType()?
But I am not sure how to do this directly, since the type is only obtained withinfind_member.


According to the docstring offind_member_simple:

Find the member type after applying type arguments from 'itype', and binding 'self' to 'subtype'. Return None if member was not found.

Sinceplain_self is always a supertype of the self type, however it may be parametrized, thetyp we get this way should be compatible with thetyp we get using the concreteself_type. However, by binding self only toplain_self, it replaces substituted polymorphic variables withNever.

Examples:

classFoo[T]:defnew[S](self:"Foo[S]",arg:list[S])->"Foo[S]": ...classBar[T]:defnew(self,arg:list[T])->"Foo[T]": ...

With this patch:

  • Foo.new becomes
    • def [S] (self: tmp_d.Foo[Never], arg: builtins.list[Never]) -> tmp_d.Foo[Never] intypeops.py#L470
    • def (arg: builtins.list[Never]) -> tmp_d.Foo[Never] insubtypes.py#L2211
  • Bar.new becomesdef (arg: builtins.list[T`1]) -> tmp_d.Bar[T`1] (✅)

Without this patch:

  • Foo.new becomes
    • def [S] (self: tmp_d.Foo[T`1], arg: builtins.list[T`1]) -> tmp_d.Foo[T`1] intypeops.py#L470 (❌)
    • def (arg: builtins.list[T`1]) -> tmp_d.Foo[T`1] insubtypes.py#L2211 (❌)
  • Bar.new becomesdef (arg: builtins.list[T`1]) -> tmp_d.Bar[T`1] (✅)

Another way to think about it is we can generally assume a signature of the form:

class Class[T]:    def method[S](self: Class[TypeForm[S, T]], arg: TypeForm[S, T]) -> TypeForm[S, T]: ...

Now, givenself_type isClass[T], it first solvesClass[T] = Class[TypeForm[S, T]] forS insidebind_self, giving us some solutionS(T), and then substitutes it giving us some non-polymorphic method

def method(self: Class[T], arg: TypeForm[T]) -> TypeForm[T]

and then drops the first argument, so we get the bound methodmethod(arg: TypeForm[T]) -> TypeForm[T].

By providing theplain_self, the solution we get isS = Never, which solve the problem.

@github-actionsGitHub Actions

This comment has been minimized.

randolf-scholzand others added2 commitsJuly 16, 2025 17:42
Co-authored-by: Stanislav Terliakov <50529348+sterliakov@users.noreply.github.com>
@github-actionsGitHub Actions
Copy link
Contributor

According tomypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

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

@sterliakovsterliakovsterliakov approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[PEP 695] Incorrect Variance Computation with Polymorphic Constructor.
2 participants
@randolf-scholz@sterliakov

[8]ページ先頭

©2009-2025 Movatter.jp