What is Python's `Ellipsis` object, and what is `...` actually used for?

`Ellipsis` is one of Python's small set of built-in singletons, alongside `None`, `True`, `False` and `NotImplemented`. The literal `...` evaluates to that same object, so `... is Ellipsis` is True and there is never more than one of it in an interpreter. Its type prints as `ellipsis` and has been reachable by a public name, `types.EllipsisType`, since Python 3.10; before that you compared against the object itself because the type had no importable name. The object is truthy, hashable, immutable in practice and carries no behaviour at all - which is precisely the point. It is a token that other code interprets. **Syntax note.** In Python 3 the `...` literal is valid anywhere an expression is, not only inside a subscript as in Python 2. That change is what made the stub-body idiom possible. **Use one: a placeholder body.** Because `...` is an expression, an expression statement made of it is a complete suite: ```python def rebuild_shard(name: str) -> int: ... ``` This is the conventional body in `.pyi` stub files, in `typing.Protocol` method declarations, and in overload declarations, where the point is to declare a signature without an implementation. `pass` would work identically - both leave the function returning `None` - and the difference is purely conventional: `...` reads as "the body is intentionally elsewhere", `pass` as "the body is intentionally empty". Note the trap: a function whose body is `...` is *not* unimplemented at runtime. Call it and you get `None`, silently. If a caller must not reach it, raise `NotImplementedError` instead; the ellipsis body belongs where the code is never executed, such as a stub file or a protocol declaration. **Use two: a subscript token.** Python gives `...` no meaning inside `[]`. The subscript machinery builds whatever object the brackets describe and hands it to `__getitem__` unchanged: ```python class Cube: def __getitem__(self, key): return key print(Cube()[..., 0]) # (Ellipsis, 0) print(Cube()[1:2, ...]) # (slice(1, 2, None), Ellipsis) ``` Everything interesting happens in the receiving class. N-dimensional array libraries adopted the convention that `...` stands for "as many full slices as are needed to fill the remaining axes", so `a[..., 0]` selects the first element along the last axis regardless of rank. That meaning is the library's, not the language's, and a class is free to interpret the token differently or reject it. **Use three: annotation forms.** `Callable[..., int]` means "any parameter list, returning int", and `tuple[int, ...]` means a homogeneous tuple of unknown length. In both, `...` is the ordinary object being used as a marker by the typing machinery. **Why it is a poor sentinel.** It is tempting to write `def update(alias=...)` and test `alias is ...` instead of building a private marker. The problem is ownership: `Ellipsis` is a single global object that every module in the process shares, so a caller, a framework or a serialization layer may pass it for reasons of their own, and your check cannot distinguish "omitted" from "the caller genuinely meant Ellipsis". Some libraries do adopt it deliberately as a public "leave unchanged" marker, which is a defensible published convention rather than a private one - but for a private not-supplied marker, a module-level `object()` you alone can produce is the correct tool. `NotImplemented` is out for the same reason and worse: it has a specific meaning in comparison protocols and using it elsewhere is a category error. **Small facts that come up.** `bool(...)` is True, so an ellipsis never disappears in a truth test. `Ellipsis` is a name in the builtins namespace, so it can be shadowed by a local or module-level assignment, but the `...` literal still produces the object - the literal is compiled, not looked up. `repr(...)` is `Ellipsis`. And because there is exactly one instance, an identity check is the only sensible way to test for it; `types.EllipsisType` exists mainly for `isinstance` checks and for writing the type in an annotation. In an interview this is a curiosity rather than a gate. What a strong answer shows is the shape of the reasoning: `...` is an inert object, the meaning lives in whoever receives it, and its very shared-ness is what disqualifies it from the sentinel role.