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

FIX: Typing of FuncAnimation#29984

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

Merged
tacaswell merged 1 commit intomatplotlib:mainfromtimhoffm:funcanimation-type
Apr 29, 2025

Conversation

timhoffm
Copy link
Member

func andinit_func may return None (which is ok ifblit=False). Since gating the allowed signature on the state ofblit is not feasible, we err on the side on being too permissive in the type definition: Rather not flag a type error and only raise on runtime than complain on an actually working signature.

Closes#29960.

`func` and `init_func` may return None (which is ok if `blit=False`).Since gating the allowed signature on the state of `blit` is notfeasible, we err on the side on being too permissive in the typedefinition: Rather not flag a type error and only raise on runtime thancomplain on an actually working signature.Closesmatplotlib#29960.
@timhoffmtimhoffm mentioned this pull requestApr 29, 2025
@tacaswelltacaswell merged commit2c5e469 intomatplotlib:mainApr 29, 2025
44 checks passed
@tacaswelltacaswell added this to thev3.11.0 milestoneApr 29, 2025
@vnmabus
Copy link
Contributor

Since gating the allowed signature on the state of blit is not feasible

Sorry but I do not understand. Wasn't that exactly what#29967 was trying to do?

@timhoffmtimhoffm deleted the funcanimation-type branchApril 29, 2025 15:32
@timhoffm
Copy link
MemberAuthor

Yes, but it's only a partial solution. See#29960 (comment)

@vnmabus
Copy link
Contributor

Yes, but it's only a partial solution.

The solution to that is to have two overloads: one forblit: Literal[True], with forces to return a sequence of artists, and other forblit: bool, that allows a sequence of artists andNone. Thus, in the usual case in whichblit=True is not passed as a kwarg, type checkers can detect that the return type is indeed a sequence of artists, and in the other cases it would be the same as the solution in this PR.

@timhoffm
Copy link
MemberAuthor

You are right, one could do this. However, I'm not convinced it's worth the added complexity.

My personal take on type hints is:

  • They are helpful to detect common errors early.
  • By design, they are incomplete and cannot express the richness possible with duck typing.
  • we should strike a balance between correctness and the complexity of their specification.

In this case, I think the complexity of the overload is not worth it, at least not as long as there are no simpler specifications of overloads.

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

@oscargusoscargusoscargus approved these changes

Assignees
No one assigned
Projects
None yet
Milestone
v3.11.0
Development

Successfully merging this pull request may close these issues.

[Bug]: FuncAnimation function not typed properly
4 participants
@timhoffm@vnmabus@oscargus@tacaswell
[8]ページ先頭
©2009-2025 Movatter.jp