| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
As a further suggestion for discussion, I'd also consider changing the interval for 14 days from a strict 14 days to first of month, 15th of month. We could consider regularizing all the daily intervals to be sure they fall on month boundaries. The above fails the obvious image comparison tests... |
Sorry, something went wrong.
|
Is their appetite for changing the default formatters as well, particularly for dates: I'd strip repeated entries. i.e. for "Feb 01", "Feb 08", "Feb 15", I'd strip "Feb" from the second two labels. i.e. only show month name when day == 1. Similarly, only show years when month == 1 (and day==1). That would make tick labels much more compact. To make that work properly, the rcParams for the date formaters (i.e. rcParams['date.autoformat.day']) may need to change their meaning, so this would be a breaking change, the problem being that we would need to know how to parse the strings to strip information, and allowing the user to input arbitrary formatting information would make that hard. |
Sorry, something went wrong.
|
I am open to this so long as there is clear and easy instructions on how to get old behavior back. |
Sorry, something went wrong.
|
I'll work on this. I was also thinking a tutorial on how to label axes would be useful. I think that info is in a bunch of examples all over the place, but not explained systematically. @tacaswell I only hesitate because I keep hearing rumours that you have a documentation plan. If so, I can wait for that, and help contribute to that. |
Sorry, something went wrong.
|
There is a plan to make a plan. In any outcome, the more content we have up front the less we have to write later (even if we re-organize or re-word it a bit). If matching the current API is too annoying, making a new formatter / locator (but not using them by default yet) is a reasonable course of action as well. |
Sorry, something went wrong.
|
OK, this PR makes interval_multiples the default. It also changes the tick locator for months to be 1 and 15 if the 14-day locator is called for. |
Sorry, something went wrong.
| byranges[i] = self._byranges[i][::interval] | ||
| if i == 2 and interval == 14: | ||
| # special case for monthday: Just tick 1 and 15: | ||
| byranges[i] = range(1, 16, 14) |
There was a problem hiding this comment.
Could this not simply be [1, 15] to make it more clear?
Sorry, something went wrong.
There was a problem hiding this comment.
Yep!
Sorry, something went wrong.
| def test_auto_date_locator(): | ||
| def _create_auto_date_locator(date1, date2): | ||
| locator = mdates.AutoDateLocator() | ||
| # we prob. should eventually have a test w/ interval_multiples=True |
There was a problem hiding this comment.
I think this comment is out of date.
Sorry, something went wrong.
| # FreeType, and then use that to build the ft2font extension. This | ||
| # ensures that test images are exactly reproducible. | ||
| #local_freetype = False | ||
| local_freetype = True |
There was a problem hiding this comment.
This looks extraneous.
Sorry, something went wrong.
|
|
||
| if self._byranges[i] and self.interval_multiples: | ||
| byranges[i] = self._byranges[i][::interval] | ||
| print(self._byranges[i]) |
There was a problem hiding this comment.
print() needs to go before merging.
Sorry, something went wrong.
| 5000, 10000, 20000, 50000, 100000, 200000, 500000, | ||
| 1000000]} | ||
| if interval_multiples: | ||
| self.intervald[3] = [1, 2, 4, 7, 14, 21] |
There was a problem hiding this comment.
Instead of [3] do you mean [DAILY]?
Sorry, something went wrong.
|
I agree with the basic idea here of using "nice" values by default. It would be good to get this into 3.0. |
Sorry, something went wrong.
|
Reviews addressed, squashed and rebased, API note added (that may need CI to test if it rendered correctly). |
Sorry, something went wrong.
There was a problem hiding this comment.
Looks good.
Sorry, something went wrong.
| 5000, 10000, 20000, 50000, 100000, 200000, 500000, | ||
| 1000000]} | ||
| if interval_multiples: | ||
| self.intervald[DAILY] = [1, 2, 4, 7, 14, 21] |
There was a problem hiding this comment.
Perhaps just curiosity, but why have this substitution of 4 for 3 in this case, and not in general? And isn't 21 a rather strange option? It is inconsistent with the docstring.
Sorry, something went wrong.
There was a problem hiding this comment.
To clarify, the 21 option is present in the current code as well as in the line cited above, so the inconsistency predates your PR.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, I don't know why the 21 is in there. I left it in as possibly some weird edge case, but I don't see how it'd happen.
3 vs 4?
3: 1, 4,..., 28, 31, 1
4: 1, 5, ... 25, 29, 1
So except for Feb leap years it avoids an awkward cross-month transition.
Sorry, something went wrong.
There was a problem hiding this comment.
added a couple of comments...
Sorry, something went wrong.
|
This is ready for a second review.... Relatively simple change that I think makes the date locators much better... |
Sorry, something went wrong.
Also make monthly byranges be 1 and 15
|
squashed... |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
OK, AutoDateLocator returned "not-nice" tick labels:
So like a dummy, I went and tried to implement better ticks that snapped to the tick intervals (10 minutes in this case). Then this morning I reread the code and found that lo-and-behold, it has a flag for this (interval_multiples=False)
I don't see the rationale behind the default being interval_multiples=False. Other than that it will break some existing tests, and its a breaking change. The resulting ticks look far better, and are much more amenable to panning. Tick locators are obscure enough that I never use them except in extremis, so expecting normal users to change options in them just to get something that looks somewhat rational is not putting our best foot forward.
PR Checklist