From 10k feet looks good.

Keep in mind the coming conversion to traitlets which is going to deprecate most of the getter/setter methods (set_locs and set_uselocale both fall in that camp, maybe offset_text as well). It might be better to use names without get for the public methods. Maybe Formatter.for_label and for_cursor

I have a preference for more simpler functions/classes over fewer more complex functions/classes. Having attributes/arguments that affect drawing conditional on the value of some other attribute/argument makes the API more frustrating to use.

Also going back and forth on if this should be lumped in with 2.0 style changes or 2.1. Tagged this as 2.1, but if these changes make the style changes to the offset text easier to do I am in favor of re-implementing the old API in terms of the new, using the new everywhere internally and starting the deprecation cycle on the old in 2.1 (to be removed in 2.3).

Keep in mind the coming conversion to traitlets which is going to deprecate most of the getter/setter methods (set_locs and set_uselocale both fall in that camp, maybe offset_text as well). It might be better to use names without get for the public methods. Maybe Formatter.for_label and for_cursor

What's the status of the switch to traitlets? (Specifically, is it certain that there will be a switch?) Given that the Formatter class is actually fairly self-contained, would it be OK for me to directly write a traitlets-based API? (I don't want to maintain two compatibility layers.)

I would suggest Formatter.as_label_text and Formatter.as_cursor_text, perhaps.

I have a preference for more simpler functions/classes over fewer more complex functions/classes. Having attributes/arguments that affect drawing conditional on the value of some other attribute/argument makes the API more frustrating to use.

Do you mean that you'd rather keep LogFormatterExponent and LogFormatterMathText out? I personally think that ax.get_xaxis().get_major_formatter().use_mathtext = False would be easier to use than having to import a new class and swap it in with set_major_formatter for that purpose.

We have not hit a major technical issue with traitlets yet. Unless there is
something like a show stopping unresolvable speed regression that will be
one of two main features for 2.1 (the other being the gui classes overhaul).

On Sat, Jan 2, 2016, 20:18 Antony Lee notifications@github.com wrote:

Keep in mind the coming conversion to traitlets which is going to
deprecate most of the getter/setter methods (set_locs and set_uselocale
both fall in that camp, maybe offset_text as well). It might be better to
use names without get for the public methods. Maybe Formatter.for_label and
for_cursor

What's the status of the switch to traitlets? (Specifically, is it certain
that there will be a switch?) Given that the Formatter class is actually
fairly self-contained, would it be OK for me to directly write a
traitlets-based API? (I don't want to maintain two compatibility
layers.)

I would suggest Formatter.as_label_text and Formatter.as_cursor_text,
perhaps.

I have a preference for more simpler functions/classes over fewer more
complex functions/classes. Having attributes/arguments that affect drawing
conditional on the value of some other attribute/argument makes the API
more frustrating to use.

Do you mean that you'd rather keep LogFormatterExponent and
LogFormatterMathText out? I personally think that ax.get_xaxis().get_major_formatter().use_mathtext
= False would be easier to use than having to import a new class and swap
it in with set_major_formatter for that purpose.

—
Reply to this email directly or view it on GitHub
#5787 (comment)
.

It would be nice to have this on 2.0 (I think), which won't have Traitlets. So, unfortunately, if we agree it should be on 2.0, we will have to do a non-Traitlets implementation now and a Traitlets one later. In our experience with Traitlets so far, though, this won't mean maintaining two code paths, but simply replacing to use Traitlets.

A pattern we used else where is to use the 'old-school' property model to
get both the getter/setter api + property API.

On Mon, Jan 4, 2016 at 10:19 AM Michael Droettboom notifications@github.com
wrote:

It would be nice to have this on 2.0 (I think), which won't have
Traitlets. So, unfortunately, if we agree it should be on 2.0, we will have
to do a non-Traitlets implementation now and a Traitlets one later. In our
experience with Traitlets so far, though, this won't mean maintaining two
code paths, but simply replacing to use Traitlets.

—
Reply to this email directly or view it on GitHub
#5787 (comment)
.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

This is somewhat outdated, but we could still at least consider deprecating (or rather making private) format_data, which is not actually used anywhere other than as a internal helper, as well as set_locs (per #13323).

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!