I've created a poll on this subject: https://discuss.python.org/t/sentinel-values-in-the-stdlib/8810
On Fri, May 14, 2021 at 10:33 PM Tal Einat <talei...@gmail.com> wrote: > > On Fri, May 14, 2021 at 12:45 PM Steve Dower <steve.do...@python.org> wrote: > > > > On 14May2021 0622, micro codery wrote: > > > > > > There was a discussion a while back ( a year or so?? ) on > > > Python-ideas that introduced the idea of having more "sentinel-like" > > > singletons in Python -- right now, we only have None. > > > > > > Not quite true, we also have Ellipsis, which already has a nice repr > > > that both reads easily and still follows the convention of eval(repr(x)) > > > == x. It also is already safe from instantiation, survives pickle > > > round-trip and is multi-thread safe. > > > So long as you are not dealing with scientific projects, it seems a > > > quick (if dirty) solution to having a sentinel that is not None. > > > > I don't think using "..." to indicate "some currently unknown or > > unspecified value" is dirty at all, it seems perfectly consistent with > > how we use it in English (and indexing in scientific projects, for that > > matter, where it tends to imply "figure out the rest for me"). > > > > All that's really missing is some kind of endorsement (from python-dev, > > presumably in the docs) that it's okay to use it as a default parameter > > value. I can't think of any reason you'd need to accept Ellipsis as a > > *specified* value that wouldn't also apply to any other kind of shared > > sentinel. > > I'll try to organize my thoughts a bit here. This is a bit long, > welcome to skip to the final sentence for the "tl;dr". > > Features one may want for a sentinel: > 1. Unique from other objects > 2. Globally unique, i.e. unique from other such sentinels (no consensus here) > 3. Clear repr (the original subject of this thread) - significant > since these often appear in function signatures > 4. Survives pickling round-trip (I brought this up since I was bitten > by this once, but others have mentioned that this is usually > irrelevant) > 5. Can be given a clear type signature (this was brought up on > twitter[1]) - significant since without this nobody can add full type > signatures even if they want to > > The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is > what I've been using for years, and I now think that it isn't good > enough. This not having a nice repr is what started this thread. > > I'd also personally prefer something simple, ideally without a new > class or module. > > There are several simple idioms using existing features that seem like > good options, so let's review those: > > 1. Ellipsis, a.k.a. `...`. This has all of the features outlined above > except #2. My main issue with using Ellipsis for this is that it could > be surprising and confusing for devs first encountering such use, and > could be relatively awkward to figure out. > > 2. An instance of a one-off class. dataclasses.MISSING is an example > of this. It is defined thus: > > class _MISSING: > pass > MISSING = _MISSING() > > Besides failing #4 (surviving pickle round-trips), its repr isn't > great: <dataclasses._MISSING object at 0x7fe14b1e2e80>. That is easily > overcome by implementing __repr__. > > 3. A one-off class: > > class MISSING: pass > > This has all of the above features except #5: having a clear type > signature (since its type is type). Using a class as a value this way > could be surprising, though. It's repr also isn't great: <class > 'dataclasses._MISSING'>. > > 4. A value of an single-valued enum, for example (from [1]): > > class _UNSET(enum.Enum): > token = enum.auto() > > This has all of the features above and is simple, just requiring a > comment to explain what it is. It's repr is a bit awkward though: > > >>> repr(_UNSET.token) > '<_UNSET.token: 1>' > > > All of these are in use by some developers, though not necessarily in > the stdlib. None is perfect, though all are probably good enough. > Since pickling is likely not relevant in most cases, I'm currently in > favor of #2 making sure to implement a nice __repr__. > > - Tal > > [1] https://twitter.com/nolar/status/1392962447166877697 _______________________________________________ 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/77ZBKCJQTG2OFY2WUL33OSJ6H3J57AEP/ Code of Conduct: http://python.org/psf/codeofconduct/