BLD: Remove mypy from pre-commit as long its always a full run
Without supporting an incremental mode, the runtime overhead (reportably at 20s)
is unacceptable for efficient development. We can reactivate once a stable,
 incremental mode works for `pandas`.
For my understanding: what are the blockers for incremental mode for pandas? And isn't that actually what mypy does by default: https://mypy.readthedocs.io/en/latest/command_line.html#incremental-mode ? I think we may just want to comment out for now instead of deleting entirely, so that way it is easy to restore down the road. > For my understanding: what are the blockers for incremental mode for pandas? And isn't that actually what mypy does by default: https://mypy.readthedocs.io/en/latest/command_line.html#incremental-mode ?

Maybe this is only working on some systems as your reported numbers seem to be no different between cached and non-cached runs. Can you try to run with the [SQLite cache](https://mypy.readthedocs.io/en/latest/command_line.html#cmdoption-mypy-sqlite-cache) instead ? To ensure we are talking about the same thing: the 0.6 you mentioned in the other PR for a cached run, is that for a fully identical run? Or after a tiny change? 

Because what I tried was: run mypy (takes ca 20s), do a tiny non-significant 1-line change, run mypy again (still taking 20s). If I really run mypy again without any change (directly with `mypy` then, not through the commit hook, as that will be skipped if there is no change), then I also get a fast run in the order of 1s).  > To ensure we are talking about the same thing: the 0.6 you mentioned in the other PR for a cached run, is that for a fully identical run? Or after a tiny change?
> 
> Because what I tried was: run mypy (takes ca 20s), do a tiny non-significant 1-line change, run mypy again (still taking 20s). If I really run mypy again without any change (directly with `mypy` then, not through the commit hook, as that will be skipped if there is no change), then I also get a fast run in the order of 1s).

Ah, that explains it. Yeah, we should also have fast one line changes, the 0.6s were without a change. Ah, OK, that explains ;) 
Now, I did the timing with a tiny change, as in practice when iterating on a branch, you always commit *something*, so the time it takes for mypy without change doesn't really seem relevant for the pre-commit hook (eg also when black changed something in the pre-commit hook, and you directly re-commmit, mypy again takes a long time, although black already changed it before mypy was run the first time ..) What's the plan between #30814 and this one? If we merge #30814, then this isn't needed? > What's the plan between #30814 and this one? If we merge #30814, then this isn't needed?

This PR here was only a immediate mitigation as I wanted to provide an option to work with less pain again. Given that we have #30814, this can be closed after merge. Changed the milestone to `No Action` so that it is clear we are not intending to merge this one.