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 haveFormatter.__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 haveFormatter.__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_wrapperwrapper.__signature__ = inspect.signature(originalInit)

work?

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

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

Gotcha I'll give that a shot

That may work, but the more standard/complete way of doing it is to usefunctools.wraps, as the code fromthe 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 usefunctools.wraps, as the code fromthe 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 aninit 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 aninit 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 checkingif '__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 thateval(repr(obj)) == obj and I agree with the suggestion that in the locator / formatter example being able to use the title ofrepr(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 😞

@tacaswell, just a heads up that needing to be current state was discussed in the issue and@Daniil-Aleshechkin already prototyped something there#21898 (comment)

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 :)