gh-10906: make Any a class on 3.11+

[graingert]

Fixes #10906

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

pydantic (https://github.com/samuelcolvin/pydantic)
- pydantic/fields.py:353: error: Incompatible types in assignment (expression has type "object", variable has type "type[Any]")  [assignment]
- pydantic/_internal/_generate_schema.py:1444: error: Argument 2 to "_generate_parameter_schema" of "GenerateSchema" has incompatible type "object"; expected "type[Any]"  [arg-type]

hydra-zen (https://github.com/mit-ll-responsible-ai/hydra-zen)
- src/hydra_zen/structured_configs/_utils.py:317: error: Incompatible return value type (got "object", expected "type")  [return-value]
- src/hydra_zen/structured_configs/_utils.py:324: error: Incompatible return value type (got "object", expected "type")  [return-value]
- src/hydra_zen/structured_configs/_utils.py:335: error: Incompatible return value type (got "object", expected "type")  [return-value]
- src/hydra_zen/structured_configs/_utils.py:382: error: Incompatible return value type (got "object", expected "type")  [return-value]
- src/hydra_zen/structured_configs/_utils.py:390: error: Incompatible return value type (got "object", expected "type")  [return-value]
- src/hydra_zen/structured_configs/_utils.py:417: error: Incompatible return value type (got "object", expected "type")  [return-value]
- src/hydra_zen/structured_configs/_implementations.py:2196: error: Generator has incompatible item type "tuple[str, object, SupportedPrimitive]"; expected "tuple[str, type[Any]] | tuple[str, type[Any], Any]"  [misc]
- src/hydra_zen/structured_configs/_make_config.py:85: error: Incompatible types in assignment (expression has type "object", variable has type "type")  [assignment]
- src/hydra_zen/structured_configs/_make_config.py:458: error: Argument "hint" to "ZenField" has incompatible type "object"; expected "type"  [arg-type]

ibis (https://github.com/ibis-project/ibis)
+ ibis/expr/operations/__init__.py:13: error: Incompatible import of "Any" (imported name has type "type[ibis.expr.operations.reductions.Any]", local name has type "type[typing.Any]")  [assignment]
- ibis/expr/types/logical.py:280: error: "object" not callable  [operator]
+ ibis/expr/types/logical.py:280: error: Too many arguments for "Any"  [call-arg]
+ ibis/expr/types/logical.py:280: error: Unexpected keyword argument "where" for "Any"  [call-arg]
+ note: "Any" defined here
+ ibis/expr/types/logical.py:280: error: Incompatible types in assignment (expression has type "Any", variable has type "UnresolvedExistsSubquery")  [assignment]
- ibis/backends/polars/compiler.py:674: error: No overload variant of "register" of "_SingleDispatchCallable" matches argument type "object"  [call-overload]
- ibis/backends/polars/compiler.py:674: note: Possible overload variants:
- ibis/backends/polars/compiler.py:674: note:     def register(self, cls: type[Any], func: None = ...) -> Callable[[Callable[..., Any]], Callable[..., Any]]
- ibis/backends/polars/compiler.py:674: note:     def register(self, cls: Callable[..., Any], func: None = ...) -> Callable[..., Any]
- ibis/backends/polars/compiler.py:674: note:     def register(self, cls: type[Any], func: Callable[..., Any]) -> Callable[..., Any]
- ibis/backends/clickhouse/compiler/values.py:812: error: Incompatible types in assignment (expression has type "object", variable has type "type[Binary]")  [assignment]
+ ibis/backends/clickhouse/compiler/values.py:812: error: Incompatible types in assignment (expression has type "type", variable has type "type[Binary]")  [assignment]
+ ibis/backends/clickhouse/compiler/values.py:812: note: "type.__call__" has type "Callable[[VarArg(Any), KwArg(Any)], Any]"

prefect (https://github.com/PrefectHQ/prefect)
- src/prefect/settings.py:577: error: Argument 1 to "Setting" has incompatible type "object"; expected "type[Any]"  [arg-type]

[Avasam]

The last stubtest issue would be resolved by adding Any.__new__'s definition. However I'm not entirely certain how to type it. I'm guessing def __new__(cls, *args: object, **kargs: object) -> Self: .... But I'm curious if we can somehow represent that TypeError statically.

Anyway mypy seems happy from the mypy_primer results. "new" ibis issues are mostly rewords of a symbol name conflict.
pyright however, really isn't happy about this change, good luck with that! ^^"

[srittau]

The primer hits are interesting. This seems to fix some type annotations where Any is used as a type, like in hydra_zen:

https://github.com/mit-ll-responsible-ai/hydra-zen/blob/main/src/hydra_zen/structured_configs/_utils.py

def sanitized_type(...) -> type:
    ...
    return Any
    ...

Or in pydantic (https://github.com/pydantic/pydantic/blob/main/pydantic/_internal/_generate_schema.py):

def _generate_parameter_schema(self, ..., annotation: type[Any], ...): ...

def _callable_schema(...):
    ...
    if ...:
        annotation = Any
    else:
        annotation = type_hints[name]
    ....
    self._generate_parameter_schema(..., annotation, ...)

Edit: On the other hand the hits in ibis seems to be due to some incompatible import shenanigans.

[srittau]

As I implied in #10906, this would be a nice to have, but non-essential change (when the remaining stubtest problems are ironed out). But we wouldn't merge this if/as long as pyright is negatively affected. I haven't looked in depth at the pyright failures, but at least a large bunch of them seem to be @property related.

[JelleZijlstra]

The type return annotation in hydra-zen is simply incorrect though: they also have a branch that returns a Union (https://github.com/mit-ll-responsible-ai/hydra-zen/blob/cfa9f37175eeab39f2a1f52754c58391947c0ccb/src/hydra_zen/structured_configs/_utils.py#L337), which isn't a type.

[hauntsaninja]

I don't think we should do this. Any is still conceptually very much a special form.

In the past, we've been quite happy to not try to reflect implementation when it comes to special objects in typing.py and I think that has been a good policy (here's a mypy issue from yesterday as a reminder of why this is fraught python/mypy#16297 ). If we do want to make a change like this, we should clarify exactly what behaviour we expect from type checkers, when targeting which versions of Python. If we're unable to decide, status quo should win since it is significantly easier to reason about.