# PEP 661: Sentinel Values **URL:** \ **Category:** PEPs\ **Created:** [June 6, 2021, 8:07am UTC](https://discuss.python.org/t/pep-661-sentinel-values/9126 "2021-06-06T08:07:06Z")\ **Posts on this page:** 1\ **Showing post:** 234
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [February 27, 2025, 10:51pm UTC](https://discuss.python.org/t/pep-661-sentinel-values/9126/234 "2025-02-27T22:51:42Z")
The Python Steering Council recently discussed [PEP 661](https://peps.python.org/pep-0661/), Sentinel Values. This post is on behalf of the SC. We’d like to thank Tal for writing this PEP and leading a fruitful discussion on DPO. Although we are not yet pronouncing on the PEP, the SC is generally supportive of the idea of adding official sentinel values to Python. As the use of `object()` for unique sentinels shows, the motivation for sentinels is clear, and we agree with the rationale provided in the PEP. We think that sentinels should be at least as easy to use as `object()`, while providing clear benefits over that simple and existing idiom, and we agree the implementation should be as simple as possible to achieve these goals. Here is some additional feedback on the PEP. We’re not implying that acceptance of the PEP is conditional on accepting our recommendations, but we want to give you a clear idea of what we’re thinking, and we’d like to encourage you to take advantage of [Steering Council office hours](https://github.com/python/steering-council?tab=readme-ov-file) if you’d like to discuss our feedback in person. The PEP proposes that sentinels within the same module are unique, and implements a global registry to ensure this. We think that this is “magical” behavior that isn’t supported strongly enough by the rationale and motivations in the PEP. Why is this implicit behavior necessary? Wouldn’t defining a module global sentinel explicitly and then referring to it by variable name be sufficient? We suggest that removing this behavior would keep the implementation simpler while still achieving the goals of the PEP. Along those same lines, the PEP proposes to auto-discover the module that the sentinel is defined in, while still providing an optional `module_name` argument to the constructor for cases where the auto-discovery can’t or doesn’t work. While this parallels the design of `Enum` and `namedtuple`, we aren’t convinced that this is useful for sentinels, especially if the global registry feature is removed as suggested above. We think a single `name` argument, which would be used directly in the `repr`, should be sufficient to achieve the goals of the PEP. If the user wanted to include the module name in that argument, it’s easy enough to do so explicitly. We think it’s fine for sentinels to evaluate as truthy in boolean contexts. The PEP proposes a new module called `sentinellib` which will contain a `Sentinel` class. We note however that in the [section titled “Typing”](https://peps.python.org/pep-0661/#typing), the examples use a module called `sentinels`. In either case, we think that to improve adoption by making sentinels as easy to use as the current `object()` idiom, a builtin type / callable called `sentinel` should be provided. With a simplified implementation, it may not even be necessary to implement sentinels as Python code living in a new standard library module (e.g. it could be implemented in C). Thanks again Tal, and we’re looking forward to further discussions. --- _[View the full topic](https://discuss.python.org/t/pep-661-sentinel-values/9126)._