Is there even a point in keeping Ft2Image public? It is only used internally in one location _mathtext, although one can still import it from mathtext as well.

Edit: No, one cannot import from mathtext, but it is in the stub-file for mathtext for unknown reasons.

It was removed from mathtext.py in #24984, but the type hint was not updated/not yet merged to be updated, depending on ordering of those PRs

@oscargus Is there a tool you used to automate finding this dead code? I'm interested in running a similar process on some of my other repos. Was reading this blog post the other day on Google's efforts to clean up orphaned code and got inspired.

@scottshambaugh Here, I've just used the code coverage and started from there. I guess a valid way would be to search for function/method definitions and then grep for that name in the code base (which is typically what I do once I've identified a potential candidate based on code coverage). Still require manual judgement, but I guess that is the main problem anyway: to know if it is just unused internally or if it is meant for "external" use. (For private functions/methods, it is less of a problem.)

My experience is that some static code checkers were able to do this pretty well. But primarily for other languages than Python. (I also guess it is different when you are a library compared to an application, when being active with JabRef, I relied on those tools much more than now, primarily contributing to MPL and SymPy.)

One thing I've been thinking about is if there are private methods that are tested directly (although it is not the encouraged approach) and therefore are covered, but otherwise unused?

Personally, I sometimes just try to get code coverage of things and in that way one can sometimes realize that some code really cannot be reached. Although it is not always clear where the problem is. For example, in SymPy I've not been able to reach code that clearly is handling a special case, just unknown which, and then it is not so clear if I just cannot figure out which case or if the case is now handled elsewhere. I think the corresponding cases in Matplotlib are probably things like error handling and array-conversions that may have moved elsewhere over time. When I first started contributing, I managed to find a few of those cases by simply trying to increase code coverage.

Hence, my conclusion is that one should have code coverage for all cases to start with and that the code coverage tools should report "unrelated" changes as well, to be able to detect that once modifying something.

Maybe obvious things, but at least my experience from a hobbyist perspective...

Thank you for the info! The focus on code coverage makes sense, that seems like a good guide for finding where these orphaned code is a liability and not just a clutter.