I very much second this opinion
/Christian
On Sat, 14 Nov 2020, 15.16 Joao S. O. Bueno, <jsbu...@python.org.br> wrote:
>
>
> On Sat, 14 Nov 2020 at 10:16, Nick Coghlan <ncogh...@gmail.com> wrote:
>
>> On Fri, 13 Nov 2020 at 09:39, David Mertz <me...@gnosis.cx> wrote:
>> >
>> > I have read a great deal of discussion on the pattern matching PEPs and
>> less formal discussions. It is possible I have overlooked some post in all
>> of that, of course.
>> >
>> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose
>> applies to this too :-).
>> >
>> > One idea that I cannot recall seeing, but that seems to make sense to
>> me and fit with Python's feel is using a WORD to distinguish between a
>> variable value and a binding target. That is, instead of a special symbol
>> prefixing or suffixing a name, either to indicate it is or is not a binding
>> target. Of course, whether the extra word would be used for binding or for
>> NOT binding is a question still.
>>
>> If someone was prepared to pursue this to the level of writing a 3rd
>> competing PEP, the variant I would personally like to see written up
>> is the one where capture patterns are all prefixed with the keyword
>> `as`.
>>
>> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
>> match patterns with a capture pattern, and I'm going to be amending
>> PEP 642 to propose using `as` when embedding capture patterns inside
>> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
>> From there, it's an entirely plausible step to also require the `as`
>> prefix on capture patterns in sequence patterns and as top level
>> standalone patterns.
>>
>> I personally don't think that extra step would be a good idea due to
>> the inconsistency with name binding and iterable unpacking in regular
>> assignment statements (if I liked the idea, I'd have already included
>> it in PEP 642), but I think "anchor match patterns in normal
>> expressions rather than assignment target syntax" is a credible enough
>> idea that the overall design process would benefit from having a
>> champion write it up.
>>
>> > To me these read better than the punctuation characters. But I guess
>> some folks have suggested enlisting 'as', which is a word, of course.
>>
>> Indeed, and one that doesn't look too bad for top level patterns:
>>
>> NOT_FOUND = 404
>> match http_code:
>> case 200:
>> print("OK document")
>> case NOT_FOUND: # use the variable value
>> print("Document not found")
>> case as other_code: # bind this name
>> print("Other HTTP code")
>>
>> It starts to look a bit more strange when matching sequences, though:
>>
>> match seq:
>> case as first, *middle, as last:
>> ... # Or should that be "*as middle"?
>>
>
> Although the spacing there should probably remain optional, I think
> that "* as middle" is very straightforward and easy to read.
>
>
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>> _______________________________________________
>> 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/LKRWAQX57OJANWQHG2SWL2UG4ZZRRKPF/
>> 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/GFVLLQVHN2QWNX6LWHESBGRMXHLF3Z74/
> 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/7NFU33AMGMPJDZDODMPN5VUL64RUDUW2/
Code of Conduct: http://python.org/psf/codeofconduct/
