
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