Following the continued discussion, I'm currently in favor of a simple interface using a factory function, i.e. NotGiven = sentinel('NotGiven').

I've created a new GitHub repo with a reference implementation. It also includes a second version of the draft PEP, addresses some of the additional points brought up in the latest parts of this discussion.

https://github.com/taleinat/python-stdlib-sentinels

- Tal

On Mon, May 24, 2021 at 5:28 PM Tal Einat <taleinat@gmail.com> wrote:
On Mon, May 24, 2021 at 3:30 AM Luciano Ramalho <luciano@ramalho.org> wrote:
>
> On Sun, May 23, 2021 at 3:37 AM Tal Einat <taleinat@gmail.com> wrote:
> > I put up an early draft of a PEP on a branch in the PEPs repo:
> > https://github.com/python/peps/blob/sentinels/pep-9999.rst
>
> Thanks for that PEP, Tal. Good ideas and recap there.
>
> I think repr= should have a default: the name of the class within <>:
> <NotGiven>.
>
> Sentinels don't have state or any other data besides a name, so I
> would prefer not to force users to create a class just so they can
> instantiate it.
>
> Why not just this?
>
> NotGiven = sentinel('<NotGiven>')

I'm seriously considering that now. The issues I ran into with this
approach are perhaps not actually problematic.

> On the other hand, if the user must create a class, the class itself
> should be the sentinel. Class objects are already singletons, so that
> makes sense.
>
> Here is a possible class-based API:
>
> class NotGiven(Sentinel):
>     pass
>
> That's it. Now I can use NotGiven as the sentinel, and its default
> repr is <NotGiven>.
>
> Behind the scenes we can have a SentinelMeta metaclass with all the
> magic that could be required--including the default __repr__ method.
>
> What do you think?

One issue with that is that such sentinels don't have their own class,
so you can't write a strict type signature, such as `Union[str,
NotGivenType]`.

Another issue is that having these objects be classes, rather than
normal instances of classes, could be surprising and confusing.

For those two reasons, for now, I think generating a unique object
with its own unique class is preferable.

> Sorry about my detour into the rejected idea of a factory function.

Please don't apologize! I put those ideas in the "Rejected Ideas"
section mostly to have them written down with a summary of the
considerations related to them. They shouldn't be considered finally
rejected unless and until the PEP is finished and accepted.

- Tal