On Mon, Nov 02, 2020 at 03:31:44PM +0100, Thomas Wouters wrote: > On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano <st...@pearwood.info> > wrote: > > > > > I really don't get why so many people are hung up over this minuscule > > issue of giving `_` special meaning inside match statements. IMO, > > consistency with other languages' pattern matching is more useful than > > the ability to capture using `_` as a variable name. > > > > Allow me to explain, then: structured pattern matching is (even by > admission of PEPs 634-363) an extension of iterable unpacking. The use of > '_' as a wildcard pattern is a sharp break in that extension. In the > structured pattern matching proposal, '_' is special syntax (and not in any > way less so than '?') but *only* in cases in match statements, not in > iterable unpacking. It *already* isn't consistent with '_' in other > languages, and we can't fix that without breaking uses of _ for gettext, > not to mention other situations existing code uses '_' as something other > than an assign-only variable.
Right. This is a small inconsistency in the meaning of `_` between match statements and other statements: 1. In a `case` statement (but not the block following the case line?), `_` is a soft keyword with special meaning as a wildcard match. 2. Elsewhere, `_` is an ordinary name but special by convention. We've had soft keywords before, like `as`, `async` and `await`, and the world didn't end. The intention is to have them again in the future: https://docs.python.org/3/library/keyword.html#keyword.issoftkeyword Is it your intention to argue against all soft keywords, or just this one? > Using '_' in structured pattern matching means any use of '_' becomes an > extra burden -- you have to know whether it's a name or not based on the > surrounding context. We've had this burden ever since Python introduced strings: x = a + _ # It's a name. x = a + '_' # It's a string. And f-strings have added to that burden: x = a + f'_{_}' # It's both a string and a name! I don't think this is a heavy burden, and I don't fear this will be a heavy burden either: case _: # It's a wildcard pattern. if _: # It's a name. If I can cope with strings, with our without an f-prefix, I can cope with underscore being context-dependent. I agree that your statement is objectively true: > The use of something else, like '?', leaves existing uses of '_' > unambiguous, and allows structured pattern matching and iterable > unpacking to be thought of the same. but your argument still doesn't convince me. Using `?` would solve that problem, but I don't think that's a problem that needs solving, and furthermore it would introduce other problems in its place: - `?` as a wildcard token is ugly (that's a personal, subjective judgement); - it's confusable with it's use in regexes (things that are different should not look the same); - and it clashes with the wildcard used in most(?) other languages with pattern matching. I have not done a full review, but I believe that `_` is a wildcard pattern in Clojure, Kotlin, Haskell, Scala, Ocaml, F# and Rust, among others. We have no obligation to make Python look like other languages, but by the same token we need not be different just for the sake of being different. There's value in picking the same syntax, or at least similar syntax, as other languages. I expect to spend a long time learning how to read pattern matches before I am as fluent with them as I am with other Python code, but the wildcard pattern is probably one of the simplest parts to grasp. And the beauty is that I can look at (say) Haskell pattern matching code, and even if I can recognise nothing else, I can recognise the underscore and the `|` used for alternatives, and that gives me a toe-hold to start deciphering what I am reading. So while I acknowledge the issues you mention, I just don't think they are important. To me, the benefit of using underscore outweighs the negatives. -- Steve _______________________________________________ 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/7MSBGM7HGS324V4I3FCRYIW3FDH6GZ25/ Code of Conduct: http://python.org/psf/codeofconduct/
