You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since this PEP proposes a change to the type system (an extension of the values allowed in Literal[]), the Typing Council is also looking at it. We'll discuss internally and share our opinion here if the Steering Council thinks it's helpful.
The PEP currently proposes to use Literal[SentinelName] as the type annotation to describe the type of a sentinel object. We prefer to support SentinelName directly without the need to wrap it in a Literal . This would require the sentinel base class to supply a __or__ method to support unions, which would be straightforward. The most common sentinel value used in Python is None, and it is special-cased in the type system to not require Literal[None] in a type annotation. Since type checkers (both static and runtime) will already need to special-case sentinels, we wouldn’t gain any simplicity by forcing users to wrap sentinels in Literal[].
A suggestion came up to allow both forms in type annotations, Literal[SentinelName] and SentinelName. We prefer to keep only the latter so we don’t introduce redundant ways to describe the same type.
(Note from me personally: The change we're recommending here aligns with something Tal already said he was planning to change in the PEP, leading to Petr's message above.)
Reacted by Daniël van Noord, Tal Einat, Scott Nealon, Kalle Møller and Daniel Sperber
Also, please note that the current proposal suggests adding a new stdlib module, "sentinellib". It has been suggested to add a new "sentinel" builtin, instead, or to add this to the "typing" module; I consider all of these to be valid options.
Please (again) consider PEP 661, Sentinel Values. I know there's little time left for Python 3.15, but I hope we can still make it.
I just merged a PEP change to make sentinel a builtin instead of a new module and add a C API: python/peps#4923 . This change is now live at https://peps.python.org/pep-0661/ . I also have a draft implementation at python/cpython#148831 so that we can quickly merge the change if the SC decides to accept this change for Python 3.15.
Reacted by Adam Turner, Bartosz Sławecki and Harmon
Reacted by Alex Waygood, Daniël van Noord, Adam Turner, Brian Schubert, Chau Chun Pang, Peter Bierma, Bartosz Sławecki, Pieter Eendebak and M. Kocher
Activity
JelleZijlstra commentedon Oct 14, 2024
Since this PEP proposes a change to the type system (an extension of the values allowed in
Literal[]), the Typing Council is also looking at it. We'll discuss internally and share our opinion here if the Steering Council thinks it's helpful.encukou commentedon Oct 15, 2024
Note that there is some more discussion on Discourse, and the PEP might need to be changed.
JelleZijlstra commentedon Oct 16, 2024
On behalf of the Typing Council:
The PEP currently proposes to use
Literal[SentinelName]as the type annotation to describe the type of a sentinel object. We prefer to supportSentinelNamedirectly without the need to wrap it in aLiteral. This would require the sentinel base class to supply a__or__method to support unions, which would be straightforward. The most common sentinel value used in Python isNone, and it is special-cased in the type system to not requireLiteral[None]in a type annotation. Since type checkers (both static and runtime) will already need to special-case sentinels, we wouldn’t gain any simplicity by forcing users to wrap sentinels inLiteral[].A suggestion came up to allow both forms in type annotations,
Literal[SentinelName]andSentinelName. We prefer to keep only the latter so we don’t introduce redundant ways to describe the same type.(Note from me personally: The change we're recommending here aligns with something Tal already said he was planning to change in the PEP, leading to Petr's message above.)
taleinat commentedon Oct 18, 2024
Thank you @JelleZijlstra and members of the Typing Council! Your opinions and feedback are greatly appreciated.
I now agree that
SentinelNameis preferable toLiteral[SentinelName]. I greatly prefer onlySentinelNamerather than both options.taleinat commentedon Oct 25, 2024
Please note that the PEP has been amended to reflect the changes to typing as described by @JelleZijlstra above.
Yhg1s commentedon Oct 25, 2024
FYI, the current SC decided to leave this PEP for the next SC to decide, given that SC elections are very soon (https://discuss.python.org/t/steering-council-nominations-will-open-november-7th-2024).
taleinat commentedon Jan 26, 2025
I've created a PR with suggested post-submission changes to the PEP proposal.
python/peps#4232
I understand that the SC has recently begun reviewing this proposal. If possible, please consider the proposal to include these changes.
taleinat commentedon Jan 26, 2025
Also, please note that the current proposal suggests adding a new stdlib module, "sentinellib". It has been suggested to add a new "sentinel" builtin, instead, or to add this to the "typing" module; I consider all of these to be valid options.
gpshead commentedon Feb 6, 2025
SC review status: still on our radar, we're catching up on the latest in the Discuss thread before we can make any decisions.
warsaw commentedon Mar 20, 2025
The SC is waiting for a response on our offer of office hours to @taleinat
Until then we are in a holding pattern for PEP 661.
warsaw commentedon Apr 10, 2025
The SC has decided to defer PEP 661. I'm going to close this ticket, but please do consider reopening this for Python 3.15.
JelleZijlstra commentedon Apr 21, 2026
Please (again) consider PEP 661, Sentinel Values. I know there's little time left for Python 3.15, but I hope we can still make it.
I just merged a PEP change to make
sentinela builtin instead of a new module and add a C API: python/peps#4923 . This change is now live at https://peps.python.org/pep-0661/ . I also have a draft implementation at python/cpython#148831 so that we can quickly merge the change if the SC decides to accept this change for Python 3.15.hugovk commentedon Apr 24, 2026
The SC accepted, congratulations!
https://discuss.python.org/t/pep-661-sentinel-values/9126/337
JelleZijlstra commentedon May 16, 2026
I'd like the Steering Council's approval for two changes to the PEP: add a
repr=argument, and make the__module__attribute writable.warsaw commentedon May 19, 2026
Hi @JelleZijlstra - the @python/steering-council approves those changes. Thanks for making this feature great for 3.15!