Mailing List Archive

1 2  View All
Re: PEP 642 v3: Explicit patterns for structured pattern matching [ In reply to ]
On Sun, 10 Jan 2021, 2:55 am Paul Moore, <p.f.moore@gmail.com> wrote:

> On Sat, 9 Jan 2021 at 14:54, Nick Coghlan <ncoghlan@gmail.com> wrote:
>
> [...]
> > And I've already said I'd be fine with making the colon mandatory if the
> SC share that view.
>
> So the response to my comment that omitting the colon makes it hard to
> see that it's a dictionary unpacking is either "don't use that form if
> you don't like it" (which as we all know doesn't account for the
> problem of dealing with other people's code) or "the SC can make the
> colon mandatory" which seems to me to be extending the SC's role to
> designing the syntax rather than just approving the proposal. And
> means that the PEP we're debating might not be what gets accepted.
> Which isn't how I understood the process to work, but OK.
>

It's the same process any PEP goes through: comments from the PEP delegate
carry more weight than general review comments, as ignoring them risks
getting the PEP rejected.

>
The SC haven't provided any feedback on the submitted version of 642 yet,
so I don't know at this point if they share the concern that allowing
omitting the key/value separating colon to be omitted pushes mapping &
instance attribute patterns too close to looking like a variation on set
syntax instead of mapping syntax.

I do accept that it's a legitimate concern, it's just also a feature that's
easy to drop if the SC agrees it is problematic.


> And if the colon is mandatory, the syntax is {"text": as message,
> "color": as c}. Which is essentially the same as PEP 634 with an
> additional "as". Which basically makes this a somewhat disguised
> version of "add a marker to indicate the variable to be bound".


It isn't disguised at all, as I state it in the PEP's Design Discussion
section:

"""... instead requiring that all uses of bare simple names for anything
other than a variable lookup be qualified by a preceding sigil or keyword"""

(from
https://www.python.org/dev/peps/pep-0642/#requiring-explicit-qualification-of-simple-names-in-match-patterns
)

Meh.
> We've been down this route, some people want bindings to be explicitly
> marked, other people don't. I don't feel compelled to have explicit
> markers, I like the "match pattern looks like what's being matched"
> feature of PEP 634,


PEP 634 doesn't have that feature for class patterns in general, only for
classes like data classes, where the constructor signature is carefully
aligned with the match arguments.

For positional args, PEP 642 would also align in those carefully
constructed cases, so it's only the new syntax for attribute matching where
things differ.

For mapping patterns, I think you've made a reasonable case that the colon
should be required even when unconditionally binding names, so it wouldn't
surprise me at all if the shorthand to omit them gets rejected by the SC
(or at least moved to the "Deferred Ideas" section).

> What other syntax do we have that binds to the right without "as"?
> Allowing it at all is only as old as with statements, but that's still more
> precedence than ":" and "=" have for being used that way.
>
> None at the moment, but that's not my point. My point is that patterns
> are more like expressions than statements, and all current uses of
> "as" for binding are in statements. Expressions typically use
> punctuation rather than keywords, so there's no compelling argument
> that the syntax for "binding the RHS" *in expressions* has to be "as".
>

But PEP 634 uses "PTRN as NAME" as well.

The only difference in this regard between the two PEPs is that 634 allows
"_ as NAME" to be shortened to just "NAME" (omitting both the pattern and
the keyword), while 642 only allows "__ as NAME" to be shortened to "as
NAME" (omitting only the pattern).

You say "we use as in statements, so let's re-use that", I say "we use
> punctuation in expressions, and a keyword looks clumsy and verbose". I
> don't believe that point has ever been addressed directly, which is
> why I get frustrated that arguments about "as" seem to be getting
> redirected into arguments about binding to the right all the time.
>

I didn't realise it was an argument you were trying to make.

Cheers,
Nick.


> >
>
Re: PEP 642 v3: Explicit patterns for structured pattern matching [ In reply to ]
Hello,

On Sun, 10 Jan 2021 12:08:05 +1000
Nick Coghlan <ncoghlan@gmail.com> wrote:

[]

> PEP 634 doesn't have that feature for class patterns in general, only
> for classes like data classes, where the constructor signature is
> carefully aligned with the match arguments.

You see, if PEP622/PEP634 contained clause like: "class patterns may be
applied only to namedtuple types (and their subclasses) and dataclasses
(and their subclasses)", then I personally would be happy. But if
PEP622 draft would have contained such a clause, it would be removed
before publishing anyway, because:

1. Enforcing such a check is more trouble/overhead.
2. There's no need to police users such deep, e.g. what if someone
writes a class which has API *like* namedtuple/dataclasses, without
formally being one?

And that's the point. If you have a class:

class MyCls:
def __init__(self, val, nm):
self.val = val; self.name = nm

, and you normally use it like: MyCls(nm="foo", val=123), then when
you'll try to use it with pattern matching, you'll immediately see
what's wrong with your class: you need to use the same name for
constructor arg and a related attribute (if you don't want to see funky
discrepancies).

To come to that, you don't need to read anything, it'll come naturally.
In full accordance with Python approach of "gentle, but exciting (not
depressing) and eventually high, learning curve", where next step is
naturally guided by your previous steps.

And of course, for people who prefer to read, PEP634/etc. in
"informational" part should have a recommendation like "Class pattern
matching syntax best works with namedtuples and dataclasses, or classes
which follow their design pattern of "no data hiding", e.g. names of
attributes should match names of constructor arguments, as both are
public interface of such a class".

> For positional args, PEP 642 would also align in those carefully
> constructed cases, so it's only the new syntax for attribute matching
> where things differ.

And that's the biggest trouble with PEP642. "Conflating set syntax with
dict semantics" is an easy case (to both see and fix), that's why I
talked about it first.

Introducing 2nd syntax to match against objects, so, there're two
syntaxes to use against objects, and one of them is completely new
to Python - that's the real problem of PEP642.

And I patiently continue this thread, hoping that people whose argument
would be along the lines of "I teach Python, and I don't want to teach
my students 2 ways of doing the same thing, and which way use when. Why,
if PEP634 offers just one way?"



--
Best regards,
Paul mailto:pmiscml@gmail.com
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/CVSPPY6B7NTY6CP7K77YLYHHRUB7PKLS/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: PEP 642 v3: Explicit patterns for structured pattern matching [ In reply to ]
On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky, <pmiscml@gmail.com> wrote:

> And I patiently continue this thread, hoping that people whose argument
> would be along the lines of "I teach Python, and I don't want to teach
> my students 2 ways of doing the same thing, and which way use when. Why,
> if PEP634 offers just one way?"
>

They don't do the same thing, though. One does traditional duck typing
(checking for the presence of a specified set of attributes on an object),
while the other matches a sequence of attributes specified by the class.

PEP 634 just conflates the two tasks into a single call-like syntax that
may or may not bare any resemblance to the type's constructor signature.

Cheers,
Nick.

>


>
Re: PEP 642 v3: Explicit patterns for structured pattern matching [ In reply to ]
Hello,

On Tue, 12 Jan 2021 00:11:33 +1000
Nick Coghlan <ncoghlan@gmail.com> wrote:

> On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky, <pmiscml@gmail.com>
> wrote:
>
> > And I patiently continue this thread, hoping that people whose
> > argument would be along the lines of "I teach Python, and I don't
> > want to teach my students 2 ways of doing the same thing, and which
> > way use when. Why, if PEP634 offers just one way?"
> >
>
> They don't do the same thing, though. One does traditional duck typing
> (checking for the presence of a specified set of attributes on an
> object), while the other matches a sequence of attributes specified
> by the class.

Yes, as I mentioned, I grokked the "construction" you made in your PEP,
and under given premises, it's a neat construction. But I don't think
that premises under which you did that are "right".

And from point of view of an average Python programmer, they both apply
to objects, so from that PoV, they "do the same thing".

> PEP 634 just conflates the two tasks into a single call-like syntax
> that may or may not bare any resemblance to the type's constructor
> signature.

But pattern matching concept in the first place conflates "instance-of"
checks and usual one-by-one comparisons of contained values with some
references, and extraction of other contained values.

That's how we treated the matter for decades - we knew that on the
other side, the esoteric functional languages use "pattern matching".
And we smiled at that, and told ourselves that our imperative languages
are more expressive - by combining our individual "isinstance" and
scalar comparisons we can easily achieve the same effect as pattern
matching, but also tons of other effects. Fast forward, and we have
slightly adjusted definition of "expressivity" - it's not "when you can
do anything with low-level means, combining them verbosely", it's "when
you can do practically useful things concisely/without extra verbosity".

In that regard, PEP642:

1. Steals some generality/expressivity from PEP634, limiting "Cls(a, b)"
style patterns to only classes which define __match_args__.
2. Hastily adds new pattern matching syntax, "obj{.a, .b}". But PEP634
forecasts that beyond patterns which it describes, it's easy to imagine
that over time, more of useful patterns can be added (up to
user-defined patterns). It just says that it doesn't want to haste with
trying to defining those right away, instead tries to lay the
grounds for the pattern matching per se.

> Cheers,
> Nick.

--
Best regards,
Paul mailto:pmiscml@gmail.com
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/CW2MFXT5CCOVY7PLJ3XUOAGLGIFG2H3V/
Code of Conduct: http://python.org/psf/codeofconduct/

1 2  View All