[apologies for the duplicate to Guido, used reply instead of reply to all] To summarize my previous unanswered post, I posted a +1 to the "defaulting to binding vs interpreting NAME as a constant" is a dangerous default. And I submitted a couple of alternate syntactic ways to denote "capture is desired" (the angle brackets, and the capture object). I think both are reasonably readable, and one of them doesn't even add any unusual syntax (not even the "dot prefix")
As an elaboration on that, after reading the discussion and trying to not repeat what has previously been said: - I think there's a mismatch between an assumption made by the authors vs what many of us are posting here, which is explicitly stated in " https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern"; : Quoting the PEP: «the name patterns are more common in typical code, so having special syntax for common case would be weird». Even if I think a popular use case would be analysing and deconstructing complex nested structures (like ASTs), I think roughly half of the uses will actually be for "the switch statement we never had", where all branches would be constants. I've been writing a lot of code like that these last couple of weeks, so I may be biased (although the PEP authors may have been writing AST visitors this last week and may be biased the other way ;-) ) - As a sub point, I can understand if the PEP authors argue "match is not for that, use if/elif/dicts of functions in that case like you did before and ignore this PEP", but if that's the case, that should be explicit in the PEP. - I am fairly sure (as much as one can be of the future in these things) that with this PEP approved as is, linters will add new rules like "you have more than a top level name pattern, only the first one will match. Perhaps you wanted constant patterns?" and "your pattern captures shadow an existing name" and "a name you bound in a pattern isn't used inside the pattern". These will definitely help, but for me "how many new linter rules will be needed if this language change is introduced" is a good measure of how unelegant it is. - Perhaps arguing against myself, I know that, thanks to my regular usage of linters, I personally won't suffer much from this problem (once they get updated). But I also teach Python to people, and I feel that I'd have to add this to the list of "gotchas to avoid" if the PEP passes as is. Again, I can't write this email without saying that this feature is great, that the effort put in this PEP is really palpable, that I'd love to find the way to get it accepted, and that even if I'm normally conservative upgrading python versions and waiting my environment to support it fully, this will likely be the first time that I upgrade just for a language feature :) On Wed, 24 Jun 2020 at 20:44, Guido van Rossum <gu...@python.org> wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please add > your issue *concisely* to this new thread. Note that the following issues > are already open and will be responded to separately; please don't bother > commenting on these until we've done so: > > - Alternative spellings for '|' > - Whether to add an 'else' clause (and how to indent it) > - A different token for wildcards instead of '_' > - What to do about the footgun of 'case foo' vs. 'case .foo' > > (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a > variable binding and '?' for a wildcard.) > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > _______________________________________________ > 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/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/NZAQQOXM4K2G4ID4FNWZ6KRDEWFSWDMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
