Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type aliases like Point3D and InternalPoint3D should probably be renamed #4016

Closed
chopan050 opened this issue Nov 13, 2024 · 0 comments · Fixed by #4027
Closed

Type aliases like Point3D and InternalPoint3D should probably be renamed #4016

chopan050 opened this issue Nov 13, 2024 · 0 comments · Fixed by #4027

Comments

@chopan050
Copy link
Contributor

chopan050 commented Nov 13, 2024

Related PR: #3375

In my attempts to add typehints to subclasses of Mobjects, I've been repeatedly facing the following problem:

There are common methods like Mobject.get_center() which are typed to return a Point3D, where Point3D is a type alias defined as a union between a NumPy array and a tuple of 3 floats. However, the actual return type is always a NumPy array, which is more precisely described by the InternalPoint3D type alias which only represents that: a NumPy array.

The values returned from those methods are normally used as NumPy arrays: we add them with other arrays, multiply them, etc. However, MyPy complains about that, because Point3D is a union with a tuple, which does not support those operations, at least not in the way NumPy arrays do.

The most straightforward solution would be to simply typehint the returns as InternalPoint3D instead. However, InternalPoint3D is described as only for Manim internal use. It does not make much sense to use something "internal" as a return value for multiple functions and methods which we encourage Manim users to call in their code.

Since there are a lot of methods and functions returning NumPy arrays like that, I would say that the best approach would be to stop treating InternalPoint3D as only internal. IMO, this requires a name change. Therefore, I propose the following:

  • InternalPoint3D is renamed to Point3D: a NumPy array, which is returned by many functions and methods.
  • Point3D is renamed to Point3DLike: anything resembling a 3D point, either a NumPy array or a tuple[float, float, float]. Users should, in general, be able to pass Point3DLike arguments (anything resembling a 3D point) to their functions and expect Point3D (always a NumPy array) return values from them.

This might require a discussion, so any opinions and suggestions are welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🆕 New
1 participant