On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote: > If "_" is a non-binding wildcard, linters will have to allow > "case _, _" otherwise it might as well not be there. And then > if it is later changed to be binding,
Why would we want to do that? Apart from the backward incompatibility of such a change, why would we want to make `_` binding? There is an effectively unlimited number of possible capture patterns available to choose from. Just use another variable. We aren't going to use `_` as a normal capturing pattern regardless of what the language allows: that would go against idiomatic Python convention. If we use `_` other Pythonistas will snigger at our lack of clue, our programs will fail code review, and linters will complain about it. And it will go against the common practice among most current pattern matching languages. > "case _, _" will > either become invalid or start forcing the two occurrences to > be equal, depending on which change is made, thus breaking > existing code. Right. We will have no good reason to remove the non-binding wildcard pattern, and very good reason to *not* break people's code by removing it. So why are we discussing this? > The only way I can see to keep our future options open in this > area is not to have a wildcard at all, Why would we want to "keep our options open" here? What benefit do we have for going against half a century of pattern matching theory and practice and common usage in other languages? There is a lot of prior art here, probably a dozen or more languages: Haskell, Rust, Nemerle, Erlang, Ocaml, Prolog, F#, Elixer, Mathematica, etc. I haven't done a full survey of the prior art, but I doubt that I have even scratched the surface here. I'm sure there are many others, depending on how widely you want to define pattern matching. Coconut already uses `_` as the wildcard: https://coconut.readthedocs.io/en/master/DOCS.html#match Were they wrong to do so? Does the Coconut community -- to say nothing of Haskell, Rust etc -- wish that they had kept their options open? > and make people use > a different throwaway name for each don't-care position in a > pattern. That would be: (1) Annoying and frustrating. (2) Misleading: using a capture pattern means you care about the value you are capturing. Using a capture pattern to bind a value you don't care about is obfuscates the code. (3) Inefficient: that would mean things you don't care about will be captured as real, potentially long-lived, name bindings. Bindings aren't free. While it is true that we don't normally care too much about wasting the odd name binding here and there, neither do we go out of our way to *intentionally* be wasteful by unnecessarily capturing values we don't care about: who_cares1 = my_list.sort() who_cares2 = print(my_list) still_don't_care = values.reverse() honestly_i_don't_care_what_this_returns = settings.update(config) especially not chosing a different name each time. -- 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/KF6FOYNQCWWKXS55EUAA7VFT43CEC4R6/ Code of Conduct: http://python.org/psf/codeofconduct/
