Hello,
On Sat, 31 Oct 2020 18:53:57 +1000
Nick Coghlan <ncogh...@gmail.com> wrote:
> On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky <pmis...@gmail.com>
> wrote:
> > I blame it on my Saturday's hazy mind, but also for the interest of
> > other readers, could you elaborate on "`==` interacts poorly with
> > other aspects of the pattern syntax"?
>
[]
> case SomeClass(some_attr=<match_pattern>):
[]
>
> If match patterns can start with "=", those both end up looking pretty
> weird (and that's assuming the tokenizer can even figure out what is
> happening in the first place - if you omitted the spaces before "=="
> in the examples below, it would come up with "== =" for "===" and ":=
> =" for ":=="):
Of course, there would need to be a space between "=" and "==", so
those could be recognized as exactly those tokens, and not as another
token, "===".
If you hint that it would be the first case of that in Python, then ...
yeah, seems to be so. But then, pattern matching is the first case when
a seemingly r-value looking expression, like 'Cls(a, b)' can actually
be l-value (i.e. bind/assign to variables). I'm afraid, we won't go
thru this journey without expanding perceptual horizons...
>
> case SomeClass(some_attr= ==EXPR):
I agree this looks ugly.
> ...
> case {some.key: ==EXPR}:
IMHO, this looks less unpretty than above, almost Ok.
> Most ad hoc examples seem to lean towards sequence matching (I guess
> because they're shorter), but it's accounting for the readability of
> class and mapping patterns that places the most constraints on the
> choice of prefix sigil.
Right, because many people are familiar with pattern matching from
languages where it's applied to algebraic data types, a clean,
simple (bordering on primitive) concept. Whereas problem of Python is
that it tries to "embrace unembraceable". And as it tries to do so,
complex things will necessarily look cumbersome, and would require
special treatment.
We already use "def foo(kw1: ann = 1, k2: ann2 = 2)" syntax, and so can
use:
> case SomeClass(some_attr = ==EXPR):
Which no longer looks as ugly as before (just unpretty).
But anyway, the talk is about using an explicit sigil, which one is
hopefully still being considered. So, "==" as a sigil has issues, but
then "?" too. There was a (seemingly) novel idea of using unary plus,
"+" as a sigil, with a clear meaning which can be derived from its
usual Python semantics: "get value of an expression (variable as a
particular case)". What about it?
"By abuse of notation" it could be used as a wildcard match too ;-).
(But as-value sigil and wildcard syntax are 2 orthogonal questions,
while PEP 642 goes a long way to conflate them, and presents that
conflation as a selling point.)
> Cheers,
> Nick.
--
Best regards,
Paul mailto:pmis...@gmail.com
_______________________________________________
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/IUFWUVFM4JTYZC2W5UQ6C5HZNI3QLGWY/
Code of Conduct: http://python.org/psf/codeofconduct/
