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 <talei...@gmail.com> wrote: > 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/WVUIDCPLQULT4THEQ3CXNARZIUSF4C2U/ Code of Conduct: http://python.org/psf/codeofconduct/
