Ellipsis vs ...

[anabelle2001]

Mypy and Pyright both accept code sample A, but not B, and i don't understand why:

# a.py
def f(x: EllipsisType) -> None:
    if x == ...:
        return
    assert_never(x)

# b.py
def f(x: EllipsisType) -> None:
    if x == Ellipsis:
        return
    assert_never(x)  #Type "EllipsisType" is not assignable to type "Never"

When loading up cpython,

>>> ... is Ellipsis
True
>>>  id(...) == id(Ellipsis)
True

This came up when writing a function where i wanted to use ... as a sentinel to indicate "Prompt the user for this value", and None as a sentinel for "This value should not exist"

[brianschubert]

FWIW, mypy will behave as expected if you use is instead of ==. In general type checkers need to be careful about narrowing types based on the result of ==, since its behavior can be freely overridden in subclasses.

[anabelle2001]

Ah, I had originally written it as x is ..., but changed it to x == ..., thinking that is must have been the wrong comparison. is is probably better, to avoid situations where x implements __eq__.

[mimizuku-the-owl]

This would pair really well with cost visibility tooling. Right now it's hard to know how much you'd save with smart routing because most setups don't track per-model spend at the session level.

We built ClawWatch to solve this — it tracks token usage broken down by model and provider per session. If Opus-as-Orchestrator lands, you could use it to see exactly how much the routing is saving you vs. a flat Opus setup.

The data we're seeing: context rebuilds after compaction eat ~30% of daily token budget on Opus. Smart routing for those "catch-up" turns alone would be significant.

[jorenham]

Pyright deviates from runtime here; so the only conclusion I can draw is that this is a bug.