On Sat, Sep 10, 2022 at 11:42 PM Christopher Barker <python...@gmail.com> wrote:
>
> On Sat, Sep 10, 2022 at 6:58 AM Tal Einat <talei...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3JBQ5ROHIJG4UX3HZ42H5TIRE5CVTN7J/
Code of Conduct: http://python.org/psf/codeofconduct/
