On Mon, Oct 18, 2021 at 10:22 PM Tal Einat <taleinat@gmail.com> wrote:
On Mon, Oct 18, 2021 at 11:17 AM Paul Moore <p.f.moore@gmail.com> wrote:
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
If this discussion leads to re-considering the chosen design, then I will indeed bring that up for continued discussion on the dedicated PEP thread (on discuss.python.org). At this point I'm still gathering information and trying to get a better understanding of what the different designs would mean for type checkers. Eric and Alex's remarks have been very helpful in that respect, including suggesting alternatives and explaining how they would have different repercussions in terms of type checking.
Certainly though, those wanting to follow the discussion on the PEP don't necessarily have to follow this thread as well, and I won't make any decisions based solely on the discussion here.
I'll also just mention, in regard to Paul's closing remark, that there may indeed be a balance to strike between typing concerns and other concerns. First and foremost, I want to try to ensure that everyone affected gets a chance to voice their thoughts and concerns. I hope to find a solution that doesn't require a hard compromise. - Tal