We should probably decide whether we want to aggressively squash anachronisms like this. I appreciate code like this can trigger peoples' sense of aesthetics, but does it help the actual code to fix it all at once? It seems this change will just wantonly break things for 3.5 users who somehow install MPL 3.1 in instances where it need not break things.

I'm going to update the version checks at https://github.com/matplotlib/matplotlib/blob/master/setup.py#L14 and https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/__init__.py#L106 to require 3.6+ instead of 3.5+, at which point you'll need to really do it on purpose to get mpl3.1 on py3.5...

If we decide tp drop a python version, compatibility should not be a criterion whether or not to change code. It should be clear that somehow installing MPL with that python version is prone for problems.

Pro change: Even though it might not seem much, this improves clarity and readability of the code. There are many different similar changes. In total, it makes a big difference if we keep all legacy stuff or if we clean out the code.

Contra change: These "small" changes make it harder to navigate the git history and find out when real changes happend.

Overall, I think the readablilty aspect outweights the negative effect, so +1 for removing unneccesarily complicated code.