Christopher Barker writes:
The current design is that sentinels with the same name from the same module will always be identical. So for example `Sentinel("name") is Sentinel("name")` will be true.
Hmm -- so it's a semi-singleton -- i.e. behaves like a singlton, but only in a particular module namespace.
I don't see why this is a problem. Sentinels are "out of band" signals, they're invalid data *for the problem at hand*. That doesn't mean they're *always* invalid data. For example, Unicode surrogate characters are invalid in conforming streams of characters like Python str, but Python uses them internally anyway as "sentinels" meaning "byte value #XX encountered in input, but is invalid there". (You might not agree that these are sentinels, but I'm hard put to see why my interpretation is incorrect.) And, of course, Unicode itself uses them in concrete representations of characters, specifically UTF-16. So sentinel usage is fundamentally private to an application as far as I can see, and the sentinel value is fundamentally arbitrary, as long as it's not valid data for the application.
I would like to see a handful of common sentinels defined. Is there a plan to put a few that are useful for the stdlib in the `sentinel` module?
I don't think this works. You end up with the problem that None has as a sentinel: mostly it's great, but occasionally application's interpretation gets in the way of the sentinel semantics because in the end Python considers it a valid datum. For modules to be composable, they need to agree on the *exact* semantics of the sentinel. If a convention based on one of the true singletons (None, Ellipsis, True, False) doesn't work, you probably want a private sentinel anyway. IMO YMMV