As someone who has actively used various PyPI available implementations of Sentinels value/objects for years now… I’ve got more thoughts as the conversation has gone on.
Having a built in callable that didn’t need to be imported would be great.
But other than that I’m kinda looking at this PEP as it stands and thinking its a step back over what I have now. If you combine the forced truthyness of the new draft and the lack of subclassing which has always been there… for about 50% of my use cases I’m basically going to have to import a different library instead of the standard library or implement my own…
One of the main points of sentinels is to guard against improper value passing, and while i get that some people have reasons for wanting implicitly True or False like behaviour as we currently have from object() and None… having the sentinel objects be comparison unique like None while True for boolean comparisons like object()… robs it of the utility and safety benefits I’d expect of a good sentinel.
I get that its odd to have a value that isn’t True or False, but thats kind of a sentinel value’s job… To be odd and unique and require explicit handling around cases where the value is a Sentinel.
The proposed implementation will require significantly more use of Look Before You Leap style coding where up front you have to check if you were passed a sentinel and make decisions about the rest of the function or module logic, or predicate all potential comparisons with code like if argument is not sentinel_value and, in order to prevent passing on values that later code or called functions, could miss-interpret as True for the sake of data processing decision making, or any of the other ways accidentally passing in a Truthy value in the wrong argument can cause miss-adventures.
It really feels to me like it should either not compare to True or False, or allow the behaviour to be turned on.