On Mon, May 24, 2021 at 6:04 AM Christopher Barker <python...@gmail.com> wrote: > > 1) “Add a single new sentinel value, e.g. MISSING or Sentinel” (under > rejected) > > I was one of the proponent of that -- but not as an alternative to having a > stadardars way to create unique sentinels, but as an addition. That's kind of > orthogonal to the PEP, but it would still be nice to have it at the same time. > > Why? There was a fair bit of discussion as to why you would not want to > require everyone to use MISSING (dataclasses, in particular), but I still > think better for the readability of everyone's code for the common case(s?) > to use the same singleton, if they can.
The way I see it, there are several clear motivations to implement one of these and make that the recommended way of defining sentinels. The further benefit of having both is less clear to me. Also, there's this in the Zen of Python: "There should be one-- and preferably only one --obvious way to do it." This strengthens my feeling that having two recommended ways of defining sentinel values, in addition to the existing None, would be undesirable. > 2) couldn't a factory function simply return a sentinel subclass? Maybe I'm > missing something, but I can't see why that would require stack frame > inspection. It seems better for each sentinel to have its own class, which makes it possible to write strict type signatures and allows better static code analysis. It also makes handling copying and unpickling simple. > But frankly Luciano's idea of a base class that can be subclassed seems the > most startightford to me. Yes, and it's what I originally suggested near the beginning of this thread :) - 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/WP5HKBQGW255SEV3O5FULRKEHJOT2CM6/ Code of Conduct: http://python.org/psf/codeofconduct/
