Skip to content

stubtest flags PEP 661 sentinel defaults, but not object() markers #22013

Closed

Description

@ariebovenberg

Bug Report

I was eager to try PEP661 support on master, but found what might be an oversight in stubtest. It flags sentinel usage against the stub's parameter type, while it does allow object-style marker objects. Since PEP661's sentinel is now the canonical way to write such a marker, I'd expect it to be allowed in such places:

To Reproduce

# foo.py
from typing_extensions import sentinel
_MISSING = sentinel("_MISSING")


def f(x=_MISSING):
    pass
# foo.pyi
def f(x: int = ...) -> None: ...
python -m mypy.stubtest foo

Expected Behavior

No errors, the same as with _MISSING = object():

Success: no issues found in 1 module

Actual Behavior

error: foo.f is inconsistent, runtime parameter "x" has a default value of type typing_extensions.sentinel, which is incompatible with stub parameter type int
Stub: in file foo.pyi:1
def (x: int =)
Runtime: in file foo.py:5
def (x=_MISSING)

Found 1 error (checked 1 module)

I get the same on Python 3.15 beta.

As described above, adding the sentinel to the stub's type (x: int | _MISSING = ...) isn't an option.

The exemption seems to be in _verify_arg_default_value:

# Avoid false positives for marker objects
and type(runtime_arg.default) is not object

It could be adjusted to include sentinel the same way.

My Environment

  • Mypy version used: master at 8d30064 (2.4.0+dev)
  • Mypy command-line flags: none
  • Mypy configuration options from mypy.ini (and other config files): none
  • Python version used: 3.14.7 (typing_extensions 4.16.0)

Activity

  1. JelleZijlstra commented on Sep 21, 2026

    @JelleZijlstra
    Member

    I think we didn't consider stubtest when adding support (cc @edgarrmondragon). PR welcome!

  2. edgarrmondragon commented on Sep 21, 2026

    @edgarrmondragon
    Contributor

    I'm taking a look

    UPDATE: #22017, but I'm curious if we're missing anything related to stubs for sentinels?

  3. JelleZijlstra commented on Sep 21, 2026

    @JelleZijlstra
    Member

    Your PR looks right, maybe we also need to change something in stubgen though?

  4. edgarrmondragon commented on Sep 21, 2026

    @edgarrmondragon
    Contributor

    Your PR looks right, maybe we also need to change something in stubgen though?

    Thanks for the hint, see #22019.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugmypy got something wrong

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions