On Mon, 18 Oct 2021 at 03:39, Eric Traut <eric@traut.com> wrote:
I think the need for a custom sentinel value already takes us well beyond the domain of "an average Python developer".
The most common sentinel in Python is `None`, and it works well in the vast majority of use cases. Plus, `None` enjoys support from the runtime (which enforces the fact that it is a singleton) and extensive support in all type checkers. For those reasons, `None` will continue to be used as a sentinel value in the vast majority of use cases even after support is added for custom sentinel values.
I appreciate the need for custom sentinel values, but these use cases are relatively rare and are typically constrained to library authors who are (almost by definition) more advanced developers. Library authors are an important and vocal constituency, but they're small in number compared to library consumers. That's something we should keep in mind when considering the relative importance of "readability for the consumer" vs "conciseness of implementation for the author".
The more I think about this, the more problems I see with the construct `MISSING = Sentinel("MISSING")`. It begs the question: should a type checker treat the symbol `MISSING` as a variable or a type alias? There are very different rules for the two, so it's important to specify which semantics are implied.
IMO, this would be better discussed on the sentinel PEP thread, as it's about the API design. I don't think we should be discussing API changes on a specialist list like the typing-SIG. If the question was *just* about how to annotate the existing design, then this might be the right place, but once we're saying that there's an issue with the agreed-on design "because of type annotation difficulties" that's something that should be brought up in the PEP discussion. (Personally, I feel that typing concerns shouldn't force us to choose a more awkward API, but I'd rather explain my reasoning in the context of the sentinel discussion where we have a concrete use case). Paul