I guess it might work in a separate PEP, but I'm also a little worried because the current PEP would make that impossible with its subtle incompatibilities with the existing unpacking syntax. Or even more inconsistent, if the assignment target syntax is extended to become similar to the match syntax but still slightly different for backwards compatibility.
The sneaky assert wasn't the main point of my idea, it was just a weird side-effect I thought looked cool. It also kind of makes sense because to me, variable assignment/iterable unpacking is like trying to fit something in a box, but idk, it can just become discouraged practice or something. I think it's ultimately just a minor drawback. Assigning to an empty tuple is already possible. The main point is that the match syntax would be able to be used in normal assignment syntax, which also means it can be used in other places such as for loops and with statements. There would be no difference between matching a *single* pattern and variable assignment, so there would no longer be two different syntaxes for doing the same thing. Flexible object destructuring would be able to be done anywhere an assignment can, just like how sequence unpacking is already possible. The powerful syntax is no longer exclusively reserved for the match statement, which is optimized for *multiple* patterns and is just extra boilerplate otherwise. The match statement would be nothing more than a convenient way to try out multiple assignment/match patterns instead of just one, which would help unify it with the rest of the language and make the language more consistent with itself, while still being just as powerful. It could even be turned into a variant of the if/elif/else block (something like "[or ]match expression as pattern"), which would make it more flexible, and more intuitive and easy to read at first glance, since the "as"/"=" explicitly spells out that it's variable binding, which would work *exactly* the same in a match statement as it does in a "for" or "with" or assignment statement. A learner would be able to read a match statement and easily figure out what it does. The current "match/case" statement requires extra learning to figure out how exactly it works, since it's completely different from the rest of the language, and the variable binding semantics between the expression and patterns is more implicit. _______________________________________________ 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/XINCSAPKEWVXTAA2F2XLQJJM6YFUDNOS/ Code of Conduct: http://python.org/psf/codeofconduct/
