BLD: Remove mypy from pre-commit as long its always a full run

[xhochy]

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.

[jorisvandenbossche]

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 ?

[gfyoung]

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.

[xhochy]

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 instead ?

[jorisvandenbossche]

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

[xhochy]

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.

[jorisvandenbossche]

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

[TomAugspurger]

What's the plan between #30814 and this one? If we merge #30814, then this isn't needed?

[xhochy]

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.

[gfyoung]

Changed the milestone to No Action so that it is clear we are not intending to merge this one.