Added __repr__ implementation on all locators and formators - #25767

For unit testing because of the nature of the feature, any parameters that get added/ changed in anyway will be coupled to the test, can someone recommend some safe classes that I can use?

I think an easy test is seeing if you can reproduce the locator and formatter examples (e.g. https://matplotlib.org/devdocs/gallery/ticks/tick-locators.html), but replace the titles with the reprs.

This is modifying the reported runtime signature of all Formatters to have Formatter.__init__(*args, **kwargs) as the only signature reported, rather than having a more informative runtime inspectable signature.

This is modifying the reported runtime signature of all Formatters to have Formatter.__init__(*args, **kwargs) as the only signature reported, rather than having a more informative runtime inspectable signature.

Yea I think I need to rebind the signature to my wrappers. Would doing something like.

wrapper = _init_repr_wrapper
wrapper.__signature__ = inspect.signature(originalInit)

work?

That may work, but the more standard/complete way of doing it is to use functools.wraps, as the code from the original issue does.

That may work, but the more standard/complete way of doing it is to use functools.wraps, as the code from the original issue does.

Gotcha I'll give that a shot

That may work, but the more standard/complete way of doing it is to use functools.wraps, as the code from the original issue does.

Seems like it fixed the wrapping issue, but now I have the problem where args is added to the signature when I think I'm creating an init method for classes that don't have one defined. Not sure exactly what's going on, because I still get the same issue when I don't add anything from this commit: d3aef45

That may work, but the more standard/complete way of doing it is to use functools.wraps, as the code from the original issue does.

Seems like it fixed the wrapping issue, but now I have the problem where args is added to the signature when I think I'm creating an init method for classes that don't have one defined. Not sure exactly what's going on, because I still get the same issue when I don't add anything from this commit: d3aef45

I figured it out after my morning run today :)

Basically checking for null doesn't account for the case when we inherit an init method. My solution is I added a marker property and checked for it. I don't want to add it to the stubs though because it's only used for this. Is there a better / standard way of adding an arbitrary marker to the function?

Basically checking for null doesn't account for the case when we inherit an init method. My solution is I added a marker property and checked for it. I don't want to add it to the stubs though because it's only used for this. Is there a better / standard way of adding an arbitrary marker to the function?

I think you'll want to be checking if '__init__' in cls.__dict__.

This is very nice technical work, however the __repr__ should represent what the current state of the objects are not what what it was initialized with! A user that is looking at a (nice looking) repr of an object is going to have the expectation that that repr represents the current state of that object, not the state of the object at some point in the past!

Unfortunately I think the solution here is much less sophisticated and much more rote: write __repr__ methods for each class. If we also add __eq__ methods we can test that eval(repr(obj)) == obj and I agree with the suggestion that in the locator / formatter example being able to use the title of repr(obj) is a good manual visualization that it still looks good.

This does bring up the issue that there are attributes on these objects that influence how they render (and thus knowing the repr of two objects is the same is not enough to be sure that they are functionally the same), but I think that it is fair to say that is (well) out of scope.

@Daniil-Aleshechkin I'm sorry we led you down this path and asked you to do a bunch of work that is not going to land in its current state 😞

Not sure exactly what's going on but is the test agent in a bad state? Only the python 3.10 agent is throwing an exception: "Traceback (most recent call last):\n File "", line 1, in \n File "/Users/runner/work/1/s/lib/matplo...ion (%s) doesn't match libtk.a version (%s)"\nRuntimeError: tk.h version (8.5) doesn't match libtk.a version (8.6)\n"

That's a known issue, but the other test failures are for the new tests here.

That's a known issue, but the other test failures are for the new tests here.

Managed to fix those. Do we know how to fix this issue?

That's up to Microsoft.

ping @Daniil-Aleshechkin any bandwidth for continuing with this?

ping @Daniil-Aleshechkin any bandwidth for continuing with this?

Ah completely forgot about this. I stopped working on it cause I was blocked on that issue with the python 3.10 test runner. Did that get resolved? If so, I can resume working :)

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.