Hi typing folks, I'm continuing to pursue adding a tool for defining sentinel values to the standard library. See PEP 616 [1], previous discussion [2] and previous thread on this mailing list [3], for more background and details. The gist of the proposal is to add a function or class, e.g. Sentinel(), for defining sentinels in a standard way, providing nice properties such as clear reprs, support for strict type signatures and surviving copying/unpickling. Old: MISSING = object() New: MISSING = Sentinel("MISSING") Besides allowing use in the stdlib, having this be defined in a PEP and included in the stdlib means that we can agree how static type analysis would handle such sentinels. So here are some questions, where I especially would like input from people implementing static type analyzers: 1. The PEP currently suggests using Literal[MISSING] in type signatures. Is this reasonable? What would this require of static type analyzer authors and maintainers? 2. What would the type signature used during definition look like? I couldn't be MISSING: Literal[MISSING] = Sentinel["MISSING"], right? Would just using MISSING = Sentinel("MISSING") be fine, relying on type inference? I assume this would require special-casing in type checkers? 3. How does Final play into this? Note that the currently proposed implementation does NOT require that the variable name be identical to the string passed to Sentinel, nor that the Sentinel object can be found using the given name in the module's namespace in order for copying/unpickling to work. Is this reasonable or should it be changed? I'd like to add 1-2 paragraphs about type checking to the PEP, addressing the above, and anything else you think is important to have well defined. - Tal Einat [1] https://www.python.org/dev/peps/pep-0661/ [2] https://discuss.python.org/t/pep-661-sentinel-values/9126 [3] https://mail.python.org/archives/list/typing-sig@python.org/thread/NDEJ7UCDP...