On Sat, Sep 10, 2022 at 11:42 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Sat, Sep 10, 2022 at 6:58 AM Tal Einat <taleinat@gmail.com> wrote:
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.
You're right, these aren't singletons. I've been careful not to use the word "Singleton" in the PEP and relevant discussion.
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?
No. The main use cases driving this design are where a *distinct* value is needed, that would not be used anywhere else for any other use. I'll Stephen J. Turnbull put this nicely in a later reply: "If a convention based on one of the true singletons (None, Ellipsis, True, False) doesn't work, you probably want a private sentinel anyway."
b) having a standard set for third party code to use -- a bit like the built-in Exceptions.
As far as I know, the main reason for the existence of Python's built-in exceptions is that they are used by Python's internals and stdlib, not as a standardized set of exceptions for users. If it was the other way around, we'd probably have a much more extensive tree of built-in exceptions. Other languages (Java comes to mind) have gone further in this direction. To my understanding, that has been avoided intentionally in Python. - Tal