<div dir="ltr">It looks like something funny is going on with your branch (It looks like there are some extra rebased commits), but other than that it look like a good start.<div><br></div><div>Could you please open a PR so it can go through the normal code review process / have CI run?</div><div><br></div><div>Tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at 10:45 AM Todd <<a href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 4, 2020 at 10:03 PM Todd <<a href="mailto:toddrjen@gmail.com" target="_blank">toddrjen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Currently setting up the tick formatting on matplotlib requires you to import a formatter from the ticker module, create an instance of that formatter, then pass that to the axis. This makes sense for complicated formatting. However, there are some obvious cases where we can probably infer the type of formatting someone wants to do if we are just given the formatter content. For example<br><div><br></div><div> * '' is probably going to be the null formatter</div><div> * A callable, besides a formatter instance, is probably going to be a function formatter</div><div> * A sequence or numpy array is probably going to be an index or fixed formatter, depending on the locator</div><div> * Any other string is probably going to be a format string formatter or string method formatter.</div><div><br></div><div>So I think we could allow the `<span>set_major_formatter` and `<span>set_minor_formatter` to take certain sorts of inputs and create the formatter automatically for the user, making such cases much, much easier. Specifically, I propose the following inputs be accepted:</span></span></div><div><span><span><br></span></span></div><div><span><span> * `None` sets it to the default formatter</span></span></div><div><span><span> * A callable (besides a formatter instance) is set to be a FuncFormatter</span></span></div><div><span><span> * An empty string, `''`, is set to be a NullFormatter</span></span></div><div><span><span> * Any other string is a StrMethodFormatter</span></span></div><div><span><span> * An abc.collections.Sequence subclass or numpy ndarray subclass is an IndexFormatter, unless the axis is using a FixedLocator in which case it is a FixedLocator. We could restrict this to just lists and numpy arrays only.</span></span></div><div><span><span><br></span></span></div><div><span><span>Any thoughts?<br></span></span></div></div></blockquote><div><br></div><div>Based on the input I have gotten so far, I have made a simplified version of the approach [1]. It only handles the cases for str and function (or rather callable, but I call it a function in the documentation). These seem to handle most use-cases reasonably well. As Antony pointed out, None is potentially confusing, and as Thomas pointed out IndexFormatter is deprecated. That left only the empty NullFormatter (with an empty str), StrMethodFormatter (with any other str), and FuncFormatter (with a callable). <br></div><div><br></div><div>Antony made a good case that we should keep the number of approaches as small as possible. Since the NullFormatter is trivially handled with an empty str, and that is really what it is behind-the-scenes, that was an obvious one to cut.</div><div><br></div><div>Antony made the good case that any str could be handled with str.format. I tried that approach initially, but the issue I ended up having is that, although it is obvious to experienced Python users, it isn't as obvious to newer users. That would mean I would need to properly communicate this workaround to users in the documentation. However, my attempts to do this ended up being longer, more complicated, and harder to understand than simply implementing the str case directly. So I ended up keeping the str and function approaches. Of course this decision is open to discussion.</div><div><br></div><div>I also updated the documentation, tests, and examples to explain these new features. Please take a look and let me know what you think. <br></div><div><br></div><div>One open issue is that I did not change any examples currently using any of these formatters, I only added the new approach. I think it might be good to change some of the simpler examples of using formatters to use this new feature in order to make formatters seem more approachable, but I haven't done that yet.<br></div><div><br></div><div>[1] <a href="https://github.com/toddrjen/matplotlib/commit/673e4b32bb8849d1de7f1180d5a48b13d68a6f34" target="_blank">https://github.com/toddrjen/matplotlib/commit/673e4b32bb8849d1de7f1180d5a48b13d68a6f34</a></div></div></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Thomas Caswell<br><a href="mailto:tcaswell@gmail.com" target="_blank">tcaswell@gmail.com</a></div>