[prev in list] [next in list] [prev in thread] [next in thread]
List: python-dev
Subject: [Python-Dev] Re: PEP 622: Structural Pattern Matching
From: Daniel Moisset <dfmoisset () gmail ! com>
Date: 2020-06-30 22:53:31
Message-ID: CAPj3Rw7_KdFi87JVcxmiRfcO8wO06oAAd=BnY92N5H20cV_9cg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi, thank you for the comments
On Tue, 30 Jun 2020 at 07:18, Greg Ewing <greg.ewing@canterbury.ac.nz>
wrote:
> On 29/06/20 8:47 am, Daniel Moisset wrote:
> > <
> https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md> .
>
>
> You seem to be trying to shoehorn all Python data structures into
> looking like alebraic types, for the sole purpose of being able to
> claim that PEP 622 is really about algebraic types rather than
> pattern matching.
>
There may be a bit of this, I like "unifying concepts". But if I have a
bias, I was heavily pushed by the writing on the PEP. Their inspirations
are explicitly Rust and Scala (which have a very strong "algebraic type"
core),, and in discussions I've seen the authors discuss F# and Haskell
(again with a strong algebraic type influence). If they started on "we were
inspired by C's and Javascript's switch statement and then added some extra
features" I would have a different vision that the focus is
multiple-choice-conditional and the rest are extras. If they mentioned
Javascript destructuring operations as inspiration I would think instead
that the focus is decomposing builtin types and the rest are extras. The
motivation starts discussing about isinstance() checks and extracting
attributes which sounds more like "we added this to have algebraic data
types and hey, now that we're here we can also include some unpacking and
have a switch statement too".
The goal of my notes was to read the PEP between lines, so there's some
personal guess and bias, but it's not out of the blue :)
I don't think that's a helpful way of looking at things. Pattern
> matching with destructuring is a more general concept. Algebraic
> types is just one of its applications.
>
I agree on this statement (except the first sentence :) )... what I'm
trying to say is that the PEP has some underlying algebraic type style and
making it explicit is a way to understand it with different eyes.
> I think your viewpoint is coloured by languages in which algebraic
> types play a much more central role than they do in Python. For
> example, in Haskell, the usual notation for lists is syntactic
> sugar for an algebraic type representing a linked list.
>
Haskell also does some shoe-horning... integers in haskell are supposed to
be an algebraic type made by the union of infinite constructors named "1",
"2", "3", ... :) Even if the implementation is nothing like that, this kind
of shoe-horning is useful allows you to have a coherent story and design,
so I'm looking for somehting close to that in Python.
> But Python lists are not linked lists, they're flexible-sized
> arrays, and you have to squint very hard indeed to see them as
> being fundamentally an algebraic type. Yet pattern matching on
> them makes perfectly good sense.
>
True. And python has already had that for ages. I'm *guessing* intent here
again, but I believe that was included into the PEP because it was easy,
not because it was the main concern to address.
> returning by default an object __dict__ or some sort of mapping view
> > on the attributes could still be fine. It's not clear to me why the
> > "keys" of this structure are placed separately.
>
> I think the PEP explains the rationale behind the design of the
> matching protocol quite well. The goal is to make it as simple as
> possible to implement in the most common cases.
>
I have improved my understanding of this. I still find the protocol weak
(but mostly the match, not the matched_args) even for the cases that are
desired to be covered, but I'm already discussing those directly with the
authors.
> For me, there should be an instance method in object (that
> > subclasses can override) that returns the algebraic structure of the
> value.
> > The PEP as-is creates different destructuring views depending on
> > which matching class you use (whicch I think relates to something
> > that was mentioned but not discussed a lot in the python-dev list
> > about Liskov sustitability).
> I think the PEP has this right. Liskov substitutability doesn't apply
> to constructors -- they're not methods, and the constructor of a
> subclass doesn't have to accept the same arguments as that of its
> base class. The same thing applies to deconstructors, since they have
> to mirror the signature of their corresponding constructors. (...)
You're right, it was not Liskov related, but the single argument default
behaviour. I was wrong about this.
[Attachment #5 (text/html)]
<div dir="ltr"><div>Hi, thank you for the comments</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 30 Jun 2020 at 07:18, \
Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 29/06/20 8:47 am, \
Daniel Moisset wrote:<br> > <<a \
href="https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md" \
rel="noreferrer" target="_blank">https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md</a>> \
. <br> <br>
You seem to be trying to shoehorn all Python data structures into<br>
looking like alebraic types, for the sole purpose of being able to<br>
claim that PEP 622 is really about algebraic types rather than<br>
pattern matching.<br></blockquote><div><br></div><div>There may be a bit of this, I \
like "unifying concepts". But if I have a bias, I was heavily pushed by the \
writing on the PEP. Their inspirations are explicitly Rust and Scala (which have a \
very strong "algebraic type" core),, and in discussions I've seen the \
authors discuss F# and Haskell (again with a strong algebraic type influence). If \
they started on "we were inspired by C's and Javascript's switch \
statement and then added some extra features" I would have a different vision \
that the focus is multiple-choice-conditional and the rest are extras. If they \
mentioned Javascript destructuring operations as inspiration I would think instead \
that the focus is decomposing builtin types and the rest are extras. The motivation \
starts discussing about isinstance() checks and extracting attributes which sounds \
more like "we added this to have algebraic data types and hey, now that \
we're here we can also include some unpacking and have a switch statement \
too".<br><br>The goal of my notes was to read the PEP between lines, so \
there's some personal guess and bias, but it's not out of the blue \
:)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I don't think \
that's a helpful way of looking at things. Pattern<br> matching with \
destructuring is a more general concept. Algebraic<br> types is just one of its \
applications.<br></blockquote><div><br></div><div>I agree on this statement (except \
the first sentence :) )... what I'm trying to say is that the PEP has some \
underlying algebraic type style and making it explicit is a way to understand it with \
different eyes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I think your \
viewpoint is coloured by languages in which algebraic<br> types play a much more \
central role than they do in Python. For<br> example, in Haskell, the usual notation \
for lists is syntactic<br> sugar for an algebraic type representing a linked \
list.<br></blockquote><div><br></div><div>Haskell also does some shoe-horning... \
integers in haskell are supposed to be an algebraic type made by the union of \
infinite constructors named "1", "2", "3", ... :) Even \
if the implementation is nothing like that, this kind of shoe-horning is useful \
allows you to have a coherent story and design, so I'm looking for somehting \
close to that in Python.</div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> But Python lists are not linked lists, \
they're flexible-sized<br> arrays, and you have to squint very hard indeed to see \
them as<br> being fundamentally an algebraic type. Yet pattern matching on<br>
them makes perfectly good sense.<br></blockquote><div><br></div><div>True. And \
python has already had that for ages. I'm *guessing* intent here again, but I \
believe that was included into the PEP because it was easy, not because it was the \
main concern to address.</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> > returning by default an object __dict__ or \
some sort of mapping view<br> > on the attributes could still be fine. It's \
not clear to me why the<br> > "keys" of this structure are placed \
separately.<br> <br>
I think the PEP explains the rationale behind the design of the<br>
matching protocol quite well. The goal is to make it as simple as<br>
possible to implement in the most common cases.<br></blockquote><div><br></div><div>I \
have improved my understanding of this. I still find the protocol weak (but mostly \
the match, not the matched_args) even for the cases that are desired to be covered, \
but I'm already discussing those directly with the authors. \
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > For me, there \
should be an instance method in object (that<br> > subclasses can override) that \
returns the algebraic structure of the value.<br> > The PEP as-is creates \
different destructuring views depending on<br> > which matching class you use \
(whicch I think relates to something<br> > that was mentioned but not discussed a \
lot in the python-dev list<br> > about Liskov sustitability).<br>
I think the PEP has this right. Liskov substitutability doesn't apply<br>
to constructors -- they're not methods, and the constructor of a<br>
subclass doesn't have to accept the same arguments as that of its<br>
base class. The same thing applies to deconstructors, since they have<br>
to mirror the signature of their corresponding constructors. \
(...)</blockquote><div><br></div><div>You're right, it was not Liskov related, \
but the single argument default behaviour. I was wrong about \
this.</div><div><br></div></div></div>
_______________________________________________
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/ONVWLWDJZWW2KGCRZPFZ3XXVKTB2JTT7/
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic