# 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:** 231
**Author:** ![techdragon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/techdragon/32/1338_2.png) [@techdragon](https://discuss.python.org/u/techdragon)\ **Post date:** [February 6, 2025, 3:41pm UTC](https://discuss.python.org/t/pep-661-sentinel-values/9126/231 "2025-02-06T15:41:56Z")
This is the core of my argument for needing some ability to define a sentinel that errors on Boolean comparisons. There is a significant body of python code that functions by passing kwargs dicts, and while it’s easy enough for a developer to introspect the call chains and decide if None, object(), etc is best… the problem is that they aren’t in control of third party code, a point update could restructure some comparisons assuming nothing is different and introduce inadvertent changes to what would happen with None/False/True comparing values… Since this will be new to the standard library, let’s add the minimal extra complexity to allow choosing or make the explicit decision to raise the exception. The effort to keep it “minimal” feels like trying to decide if a sheet of paper is too thick… technically a valid decision… and understandable given the significance of trying to get new code into the standard library… but it feels like a somewhat foolhardy line of thinking given how with or without the options, the code will still be extremely minimal and have limited impact on existing code compared to many successful new additions to core python in recent years. --- _[View the full topic](https://discuss.python.org/t/pep-661-sentinel-values/9126)._