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/
