On Mon, May 24, 2021 at 3:30 AM Luciano Ramalho <luci...@ramalho.org> wrote: > > On Sun, May 23, 2021 at 3:37 AM Tal Einat <talei...@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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HL74JC3OF7Y3F5RDYVACAFODL4E3CBI6/ Code of Conduct: http://python.org/psf/codeofconduct/
