Hi, thank you for the comments On Tue, 30 Jun 2020 at 07:18, Greg Ewing <greg.ew...@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.
_______________________________________________ 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/ONVWLWDJZWW2KGCRZPFZ3XXVKTB2JTT7/ Code of Conduct: http://python.org/psf/codeofconduct/
