Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Apr 29, 2025
Merged

FIX: Typing of FuncAnimation #29984

merged 1 commit into from
Apr 29, 2025

Conversation

timhoffm
Copy link
Member

func and init_func may return None (which is ok if blit=False). Since gating the allowed signature on the state of blit 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.

@timhoffm timhoffm mentioned this pull request Apr 28, 2025
Closed
@timhoffm
FIX: Typing of FuncAnimation
db0ec14 
`func` and `init_func` may return None (which is ok if `blit=False`).
Since gating the allowed signature on the state of `blit` 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 matplotlib#29960.
@timhoffm timhoffm force-pushed the funcanimation-type branch from 1bd5b15 to db0ec14 Compare April 28, 2025 22:27
@timhoffm timhoffm mentioned this pull request Apr 29, 2025
Closed
@tacaswell tacaswell merged commit 2c5e469 into matplotlib:main Apr 29, 2025
44 checks passed
@tacaswell tacaswell added this to the v3.11.0 milestone Apr 29, 2025
@vnmabus
Copy link
Contributor

vnmabus commented Apr 29, 2025

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?

@timhoffm timhoffm deleted the funcanimation-type branch April 29, 2025 15:32
@timhoffm
Copy link
Member Author

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

@vnmabus
Copy link
Contributor

vnmabus commented Apr 29, 2025

Yes, but it's only a partial solution.

The solution to that is to have two overloads: one for blit: Literal[True], with forces to return a sequence of artists, and other for blit: bool, that allows a sequence of artists and None. Thus, in the usual case in which blit=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
Member Author

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 free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@oscargus oscargus oscargus approved these changes

Assignees
No one assigned
Labels
topic: animation topic: typing
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