On 07/14/2020 09:22 AM, Jim J. Jewett wrote:
Larry Hastings wrote:
As for leveraging the convention of using '_' for values you don't care about in Python--that's actually why I /don't/ like it as the wildcard pattern. To date, everyone who uses '_' understands it's just an identifier, no different from any other identifier.
However, if I understand PEP 622 correctly, the places you use '_' as the wildcard pattern are also places where you could put an identifier. But in this one context, '_' doesn't behave like the other identifiers, even though in every other context in Python it still does. This is the "special case" that "breaks the rules" I alluded to above. Consistency with the longstanding semantics of '_', and consistency with other identifiers, is much more important to me than consistency with other languages for the pattern matching wildcard token.
Looking at other languages for inspiration is great, but like Larry I think we should make sure our constructs fit with Python, not with them.
I know that "case x, x:" as shorthand for "case x, __x if x == __x:" has been postponed, but it could still happen later, and it would be a problem if that ever became legal without requiring the two bindings to match. I do NOT assume that they will match if the variable happens to be _, though I suppose others might.
If we use `?` instead of `_`, then repeated `?` won't be a problem, and repeated `_` should be disallowed. Since `_` is a normal variable name, the requirement for their values to match (when that is finally implemented) would make sense, and shouldn't be a burden to remember given that that the "don't care" symbol is a `?`. -- ~Ethan~