We use the convention that underscore attributes are private. So no one should be accessing that attribute, so I don’t think you should add it until we provide a public interface.

following in the footsteps of ScalarFormatter, added a public interface (i.e. the property usemathtext).

This comment is written with respect to the first commit here.

This would at least allow to work around the issue by

plt.rcParams["text.usetex"] = False
plt.gca().xaxis.set_major_formatter(EngFormatter())
plt.rcParams["text.usetex"] = True

So even if the argument is that "private" should not be used by anyone, this is still a useful change.
Note that the above temporary rcparams change does currently not work reliably for ScalarFormatter where people need to use the "private" thingy to not have mathmode turned on for labels.

Also, I'm not actually convinced that the general approach of #12847 is useful for the EngFormatter

"${mant:{fmt}}${sep}{prefix}"

This will now lead to the numbers being rendered in a different font than the unit prefixes. I can hardly imagine that this is what people want by default, and it's especially annoying if there isn't even any workaround for it.

I agree with both the views presented here. I think I have stepped into something which is far beyond my reach... I will wait for all the experienced core developers to weigh-in before making any changes. I will be happy to implement the suggestions on how to move forward. Please feel free to take this over if it would be easier that way.

This comment is written with respect to the second commit here.

This goes in the right direction IMO. But... the useMathText argument is now interpreted inconsistently between ScalarFormatter and EngFormatter. The problem is also that the notion "MathText" explicitely means the unicode rendering used outside of tex.

Maybe some more bikeshedding is needed here?

Would the following approach work?

(1) not treating usetex and usemathtext as being equivalent inside ScalarFormatter (as suggested in #12847 (comment))
(2) Adding a new property (say useTeXMath with useTeXMath=False as the default) for formatters that allows encapsulating numbers with $$ signs -- this will allow the user to set numbers in math font and suffixes in text font in case of EngFormatter (if they want to).

Possibly... I'm not having the complete overview of ScalarFormatter currently - but it's a total mess. So once you start changing that, the rabbit hole will soon become even deeper. In fact, ._usetex and useMathText are currently mutually exclusive in ScalarFormatter.
Having a useMathText and a useTexMath argument simultaneously is sure confusing though.

As of now I think I would be happy with either of (a) leaving EngFormatter untouched, i.e. revert #12847, (b) Get the first commit here in, in case people think that the different fonts for numbers and unit prefix are acceptable.

out of those two options I think I would prefer to go with (b) since that allows for the most flexible behavior (for now). I will wait for comments from other core/experienced developers before proceeding. Ideally I would like to fix ScalarFormatter and "go down the rabbit hole" but I do not have sufficient expertise to do that.

should I proceed by reverting the change in #12847? I would appreciate some advice from core/experienced developers. Thanks!

(sorry started working on this yesterday, and got distracted)

Well, this is a fun pickle of inconsistent APIs. To check my understanding:

• Currently with ScalarFromatter detects if rcParams['text.usetex'] is True and if so uses $$ around numbers
• this is not universally desired behavior and there is a way (by poking a private attribute!) way to opt-out of this
• previously EngFormatter did not behave the same (and never used $$)
• correctly format ticklabels when EngFormatter is used with usetex = True #12847 made EngFormatter unconditionally use $$ if rcParams['text.usetex'] is True to make it consistent with ScalarFormatter
• it was pointed out that ScalarFormatter has the cut out and this PR is putting that cutout in EngFormatter too
• adding a private attribute as a control was pointed out as an anti-pattern
• now we are in a discussion about adding a public API to control this

Did I get the facts/history right?

Yes!

May I just add that allowing for the ._usetex attribute is not only about allowing users to bypass the public API, but would also simplify any future work on those formatters by using the same internal structure.
So even if the discussion about adding a public API to control this is not happening right now, or takes too long, one would still leave the code in a state that is easier to pick up from in the future.

I think(??) the end target would be to have

• Formatter.{get,set}_usetex(); the default value is None which the setter converts eagerly to rcParams["text.usetex"] (consistent with Text.{get,set}_usetex);
• Formatter.{get,set}_useMathText() (if possible with a less atrocious name but that's what we have right now); the default value is None which the setter converts eagerly to rcParams["axes.formatter.get_usemathtext"]

?

Seems correct; not to forget to have those arguments settable in the init.

Btw. relevant issue here #8436, #11718, #11586

Thanks all for the feedback. I will implement the suggestions.

I have made the changes as suggested. Please note that I have assumed an equivalence between usetex and useMathText when inserting $ signs around numbers (to be consistent with the ScalarFormatter and based on the comment here).

A positive implication of this decision:
If there are negative numbers present (when using useMathText=True), the unicode minus sign will be used (without relying on fix_minus). This will be consistent with the notion that useMathText implies unicode rendering (as mentioned in one of the comments here).

I am glad this came to a conclusion!

Does this same public API also exist on ScalerFormatter?

Could you please add a whats_new entry?

Added a what's new entry.

I don't think there is a public API for controling the usetex behavior in ScalarFormatter. I can open a new PR to add that if this is ok with the core developers.

Thank you everyone involved in this discussion for guiding me through this!

Thanks!

@pharshalp Did you end up adding a public API for usetex in ScalarFormatter?

If not, I might be able to take a crack at it over winter break.

@mattdutson I didn't end up adding a public API for usetex in ScalarFormatter (since I didn't hear from any of the the core developers -- quoting my response relevant to this).

Added a what's new entry.

I don't think there is a public API for controling the usetex behavior in ScalarFormatter. I can open a new PR to add that if this is ok with the core developers.

Thank you everyone involved in this discussion for guiding me through this!

Please feel free to take a crack at it. Thanks!