enhanced the default datetimeformatter with a dynamic one

[muendlein]

All pull requests must have an associated issue in the issue tracker. If there
isn't one, please go open an issue describing the defect, deficiency or desired
feature. You can read more about our issue and PR processes in the
wiki.

• issues: fixes [FEATURE] datetime formatting: enhance default formatting #13186
• tests added / passed
• release document entry (if new feature or API change)

[codecov]

Codecov Report

Attention: Patch coverage is 80.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 92.64%. Comparing base (e61219b) to head (bcf1285).
Report is 20 commits behind head on branch-3.5.

Additional details and impacted files

@@              Coverage Diff               @@
##           branch-3.5   #13854      +/-   ##
==============================================
+ Coverage       91.57%   92.64%   +1.06%     
==============================================
  Files             326      326              
  Lines           20737    20765      +28     
==============================================
+ Hits            18990    19237     +247     
+ Misses           1747     1528     -219     

[bryevdv]

Unfortunately, this will take more work / different approach. The issue is that the way things are done in the PR, every single axis has a different DatetimeTickFormatter instance, but all of those share one single "global" DatetimeTickFormatter for their context. That won't work.

An immediate solution could be get rid of InstanceDefault and just pass the callable DYNAMIC_DATETIME_FORMATTER for the value. That would allow for every axis to get all new unique objects. But then the ref docs will suffer, because rendering these kinds of "dynamic" defaults better is what InstanceDefault was added for.

Or perhaps InstanceDefault can be made more sophisticated in some way, but that will require new development.

[muendlein]

@bryevdv Thanks for pointing out the sided effects. However I am wondering if there have been similar cases in the past or is this the first one?
As for moving forward, do you consider your proposed immediate solution as an viable option (given the downsides)?

[bryevdv]

It's not common to have dynamic defaults, less common still have to have dynamic defaults that are model instances, and among that tiny set, I do believe this would be the first time ever a dynamic instance default itself had property that was also such.

I think you should try building without InstanceDefault, and then also build the docs to see how badly things render in the reference guide. If it's just some opaque but short repr that shows up, that's probably fine. If it's some giant mess that takes up half the page looking like a C++ error message, that is probably not fine.

[muendlein]

@bryevdv Building without InstanceDefault works out fine. When building the docs there aren't any rendering issues but of course the static (and therefore wrong) default values are shown.