-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Deprecate TexMobject and TextMobject in favour of MathTex and Tex
#391
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
Conversation
Rename TextMobject to Tex Replace all instances of TexMobject with MathTex and TextMobject with Tex. Get rid of single-use TexSymbol. Rename SingleStringTexMobject to SingleStringMathTex. Add Deprecation warnings to TexMobject and TextMobject.
| class Tex(MathTex): | ||
| CONFIG = { | ||
| "alignment": "\\centering", | ||
| "arg_separator": "", | ||
| "type": "text", | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment (non-blocking): What never made sense to me is that I would expect MathTex() to be equivalent to something like Tex(mathmode=True) or something like that. But it seems to be the other way around, and you can't even really make one from the other. But anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably change this at some point
|
SGTM. So the change is TexMobject -> Tex and TextMobject -> MathTex? |
|
I'd prefer to have Tex[t]Mobject as it is, and have Tex = TextMobject
MathTex = TexMobject |
No, exactly the other way round.
|
Why though? I was thinking we could remove those horribly confusing names entirely, but keep them for the time being so people can migrate. |
|
If you just rename them then there is no way of issuing a deprecation warning. I agree they should go away in v2.0 |
|
Because many people are already used to these names, and understand their differences, and I don't feel it's justified to force change onto them by breaking their old code. By adding aliases, and perhaps a little one-liner note in the docstrings, we can solve the problem of confusing names without breaking peoples' existing code. Also, Which looks better? Tex <memory_loc>
VMobjectFromSVGPathString <memory_loc>
VMobjectFromSVGPathString <memory_loc>
VMobjectFromSVGPathString <memory_loc>
...
TexSymbol <memory_loc>
TexSymbol <memory_loc>
TexSymbol <memory_loc> |
|
This PR doesn't break code though, it just issues warnings. I agree TexSymbol looks more convenient. |
it sounds like the latter is a more general name. If its only purpose is to serve Tex classes, then maybe it should receive that name, otherwise we could just subclass it with this name, as it could have other uses. |
I didn't see that earlier. Apologies for that. |
|
This LGTM. Are we waiting for #335 ? |
|
Alright, so we can all agree that the About the TexSymbol, I agree that |
I count four yeses. (We never decided what actually constitutes a consensus, but having approval from every dev who read this file is a good sign.)
Is TexSymbol/VMobjectFromSVGPathString going to ever be used by the end user? If so, I vote we keep it. The latter is more verbose which is useful during development, and the former is more succinct which is convenient for the user. There's nothing wrong in having an alias for convenience I think. |
I think @kilacoda is in a better position to answer this, since he worked with LaTeX quite a bit when writing As for my opinion, I don't think the end user will ever use |
|
No, it's not really used by the user, rather it's for splitting up the individual parts of the SVG ( |
|
Ok in that case I'm feeling more neutral about it. But also, it doesn't hurt to have an alias. It doesn't matter if it's used only once in the codebase if it's meant to be used for debugging. In the interest of merging this quickly, let's just leave it and move on. To clarify: I think leaving it in is the way to go because it provides convenience at very little expense. Removing it may incur in changes to users' or devs' workflows. |
|
Unmarking as draft, since the The only test that fails now is the formatting one, which should be fixed in due course I think. |
|
I've run the new, updated version of black on the files that have been touched by this PR, as per @leotrs 's suggestion. |
List of Changes
__all__for tex_mobject.pyMotivation
The names
TextMobjectandTexMobjectare incredibly confusing to new users owing to the similarity in their names and lack of information differentiating them and theTextobject which are wholly unrelated.Renaming the objects to be more specific would be very beneficial, especially to new users.
Explanation for Changes
Changes include renaming the objects as suggested, and replacing all instances of the old names with the new ones.
To ease migration from 3b1b/manim, instead of outright removing
Tex[t]Mobject, deprecation warnings have been added instead.Testing Status
Tests currently fail. I (or anyone else interested) will port the tests to the new names once #335 is merged as it refactors the testing mechanism.
Further Comments
See discord discussion starting here.
Acknowledgement