Feature proposal: an option --any-as-object to avoid false negatives

Feature

Mypy would have an option to consider any occurrence of Any as being object in order to issue a warning or error when Any is used as if it were any type more specific than object.

Related https://github.com/python/mypy/issues/3194

Pitch

It turned out that the typeshed will rather "err on the side of convenience" and use Any to avoid causing annoyance in existing codebases.
This opens the door to potential type errors at run time without ever getting so much as a warning from mypy.
This option would allow to turn the problem on its head for those who wish to do so, giving an option to err on the side of caution rather than convenience — the benefit of ensuring no runtime type errors, at the cost of more hoops to jump through.

When using the WSGI protocol for example, using --disallow-any-expr, this ended in utter confusion due to different standards seemingly applied to my code on the one hand, and the libraries on the other:

from wsgiref.types import WSGIEnvironment, StartResponse, InputStream
from typing import Iterable

def f(a: str) -> int:
	return int(a)

def wsgi_callable(environ: WSGIEnvironment, start_response: StartResponse) -> Iterable[bytes]:
	# No error:
	content_length1 = f(environ['CONTENT_LENGTH'])

	# error: Expression has type "Any":
	content_length2 = f("0" if environ['CONTENT_LENGTH'] == "" else environ['CONTENT_LENGTH'])

	return []

To have an error in one case and not the other was completely confusing to begin with, since in all logic, both expressions have the same type (str in this case). Therefore, the intuition was that they should either be both valid or both wrong.
Looking further, I discovered that in the first case, I was actually not protected against a runtime type error due to Any: https://github.com/python/cpython/blob/main/Lib/wsgiref/types.py#L29

I understand that the typeshed uses Any to avoid creating too many errors in existing code bases, but since I'm getting started from scratch I would actually like to get the "annoyance" over potential runtime type errors.
It is for the same reason that mypy already has various 'strictness' options, for users who have an approach where they value guarantees that actually hold, more than being spared to go the final mile.

The option proposed here would elegantly convert cases with potential for false negatives to cases with potential for false positives.

Thanks to jinsun on the official #python IRC for the original concept of Any → object.

Inizia leggendo la issue correlata #3194 e rivedendo le opzioni di strictness esistenti di mypy, in particolare il comportamento descritto per --disallow-any-expr. Definisci la semantica prevista dei controlli Any-to-object e i criteri di accettazione per casi come l’esempio WSGI; la issue non indica file di implementazione né test.