How do `typing.Any` and `object` differ as annotations to a type checker?

Python's type system is *gradual*: it has to describe fully annotated code and code that was never annotated, side by side, in the same program. `typing.Any` and the builtin `object` are the two tools it uses for that, and although both are often described as "anything goes", they sit in completely different places. `object` is the **top of the subtype lattice**. `Any` is **outside the lattice altogether**. ## `object`: the top type Every class in Python inherits from `object`, so every value is an `object`. A parameter annotated `object` therefore accepts anything you pass, and that is the honest way to spell "I take any value". The price is paid inside the function: a static checker will only let you use the operations `object` itself defines. That is a short list — `str()` and `repr()`, `hash()`, `==` and `!=`, `is`, `isinstance()`, and passing the value onward to something else that takes `object`. Everything else is an error: ```python def audit(value: object) -> None: print(str(value)) # fine print(value + 1) # checker error: object has no __add__ print(value.name) # checker error: object has no attribute 'name' ``` To do more you **narrow**. An `isinstance(value, int)` test inside an `if` tells the checker that within that branch the value is an `int`, and arithmetic becomes legal there. This is the whole point of `object`: it forces the question "what is this actually?" to be answered in code, not assumed. Assignment with `object` is one-directional. A `str` can be assigned to a variable declared `object`, because `str` is a subtype of `object`. The reverse is rejected: a value declared `object` cannot be assigned to a `str` variable, because the checker has no evidence it is one. ## `Any`: the escape hatch `Any` is not a type that sits above or below other types. It is a statement that checking is suspended here. It is **bidirectionally compatible**: every type is assignable to `Any`, and `Any` is assignable to every type. That second half is the dangerous one — it is why `Any` never produces an error at an assignment. Inside a function, a value typed `Any` accepts every operation: attribute access, calls, subscription, arithmetic, iteration. And crucially, the *result* of each of those operations is `Any` too. `Any` is contagious in a way `object` is not; it does not merely relax one check, it removes checking from every expression derived from it. Since Python 3.11, `Any` is also a class and may be used as a base: `class Fake(Any): ...` produces a class on which unknown attributes are accepted, which stub and test-double authors occasionally want. ## Where the difference bites: containers The distinction is sharpest with generics. `list[object]` is a list you may read anything out of, but it is not interchangeable with `list[str]` — generics are invariant, and a checker will reject passing a `list[str]` where a `list[object]` is required, because the callee could append an `int` to it. `list[Any]`, by contrast, is compatible with `list[str]` in both directions, because the element type is unchecked. `dict[str, Any]` is the most common shape in real code, and it means "the values are not checked", not "the values may be anything sensible". ## `None` and `NoneType` The leaf next to these two is `None`. In an annotation you write `None` literally — `def save(path: str) -> None:` — and the type it denotes is `types.NoneType`, re-added to the standard library in 3.10, whose only value is the singleton `None`. It is worth naming clearly because people mix it up with the bottom types: `-> None` means "this function *does* return, and the value is `None`". It is an ordinary type with exactly one member, not a type with no members. ## Choosing between them in review The question that settles almost every case is: *do I mean "any value may arrive here", or do I mean "stop checking"?* A logging helper, a generic cache key, an equality shim, a `__eq__` parameter — those accept any value and should say `object`. Deserialized JSON, a plugin loaded by name, a dependency without type stubs — there the checker genuinely cannot know, and `Any` is the honest marker, but it should be confined to the boundary and converted into a declared shape as early as possible. The practical failure mode is reaching for `Any` because `object` produced errors. Those errors were the checker doing its job: it was asking for the `isinstance` check or the narrower annotation that the code was missing.