I haven't checked the timing myself, but trusting your numbers this would be an awesome improvement!

@timhoffm I had to refactor the PR a bit since the number of attributes of some Artist classes change over their lifetimes.

The numbers changed a bit (they also depend on the temperature in my room), but there is still a significant improvement.

The inspect.getdoc is still one of the move expensive operations.

Note also #22749 which should make docstring parsing obsolete eventually.

I have a weak preference to leave these as self.xxx rather than hard-coding the class and trusting Python to do the fallback correctly (unless that kills the performance gains).

I just checked, and making is_alias a normal method instead of a class method hurts performance because then for each new instance of the ArtistInspector the cache is empty.

I agree the methods should stay as static methods, but they should be accessed via self rather than via the class object

In [1]: class Test:
   ...:     @staticmethod
   ...:     def foo():
   ...:         print('Called!')
   ...:
   ...:     def __init__(self):
   ...:         self.foo()
   ...:
   ...: t = Test()
Called!

This way if any sub-classes want to over-ride this (are overriding this) or we want to re-factor the class (maybe pull a base class out of the top?) the usage won't change.

@eendebakpt Do you feel comfortable squashing this to one commit?

Should be squashed or squash-merged.

If you want I can squash the comments and do a force push. But usually a squash-merge is preferred, so the full history remains intact.

But usually a squash-merge is preferred, so the full history remains intact.

What do you mean? If it is squash-merged there is still only one commit in the history. By default it will just concatenate all of the commit messages, but you can do the same with squashing + force push.

But usually a squash-merge is preferred, so the full history remains intact.

What do you mean? If it is squash-merged there is still only one commit in the history. By default it will just concatenate all of the commit messages, but you can do the same with squashing + force push.

I mean the history on this PR. For the main branch there will indeed only be one commit in either case.

Fair enough. I tend to view that as a bad thing because it makes it harder to tell if the branch has actually been merged in or not.

Either way, I think this is good to go once the linting issue is fixed!

Are we doing a 3.6 RC2 and if so could this still get in there? Or do we have to delay to 3.7 to be on the safe side?

I think it would be fine to pull this back for 3.6rc2.

@eendebakpt thanks and congratulations on your first contribution to Matplotlib!

We hope to see you back!

We’re about to release version 3.6, so this will be publically available in short. 🚀