[Matplotlib-devel] Easier tick formatters

[Todd]

The PR is number 16715 [1]

https://github.com/matplotlib/matplotlib/pull/16715

On Mon, Mar 9, 2020 at 2:16 PM Thomas Caswell <tcaswell at gmail.com> wrote:

> 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.
>
> Could you please open a PR so it can go through the normal code review
> process / have CI run?
>
> Tom
>
> On Mon, Mar 9, 2020 at 10:45 AM Todd <toddrjen at gmail.com> wrote:
>
>> On Wed, Mar 4, 2020 at 10:03 PM Todd <toddrjen at gmail.com> wrote:
>>
>>> 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
>>>
>>>    * '' is probably going to be the null formatter
>>>    * A callable, besides a formatter instance, is probably going to be a
>>> function formatter
>>>    * A sequence or numpy array is probably going to be an index or fixed
>>> formatter, depending on the locator
>>>    * Any other string is probably going to be a format string formatter
>>> or string method formatter.
>>>
>>> So I think we could allow the `set_major_formatter` and `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:
>>>
>>>    * `None` sets it to the default formatter
>>>    * A callable (besides a formatter instance) is set to be a
>>> FuncFormatter
>>>    * An empty string, `''`, is set to be a NullFormatter
>>>    * Any other string is a StrMethodFormatter
>>>    * 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.
>>>
>>> Any thoughts?
>>>
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> I also updated the documentation, tests, and examples to explain these
>> new features.  Please take a look and let me know what you think.
>>
>> 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.
>>
>> [1]
>> https://github.com/toddrjen/matplotlib/commit/673e4b32bb8849d1de7f1180d5a48b13d68a6f34
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
>
> --
> Thomas Caswell
> tcaswell at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20200309/15963fd7/attachment-0001.html>