I propose to mark as deprecated the parameters `ignore_errors` and `onerror` of `shutil.rmtree()`, and raise a warning if used.

The reason is I feel them unpythonic. For emulating `ignore_errors=True`, the code can be written simply with a `try-except` that passes by default all `OSError`s . The `ignore_errors=True, onerror=myHandler` case can written simply with a `try-except` that handles `OSError`s. And in the handle can be code or a call to an handler with the same paramaters `myHandler` accept.

I don't see the point of shifting the burden to the caller.  That doesn't make their code smaller, clearer, faster, easier to write, or easier to get right.   Also, deprecations almost always cause pain so we try to avoid them unless the feature is actually detrimental.

Passing ignore_errors=True is not the same as catching and silencing OSError outside of the function. In the former case you continue removing other files in the directory even if you can't remove some of them. In the latter case you stop after the first failure.

onerror gives you even more flexibility.

There’s too much code out there relying on both args (especially ignore_errors in unit tests) that would break for no real benefit.