-
Notifications
You must be signed in to change notification settings - Fork 64
The second PEP draft #113
Comments
I agree that a rewrite is in order. I’m going to focus the bulk of my time on the implementation, but I’m happy to play a part in the rewrite as well (especially reviewing to make sure the implementation is consistent with the spec). |
I am happy to help with the second draft. Is there something in particular that I should take on? |
I can pitch in depending on available time... |
I'm quite interested in taking this, under the assumption that there's some rough consensus |
Unfortunately we're still stuck getting rough consensus. There are things that could be done before that's reached, such as rewriting the motivation, summarizing common objections, or coming up with a better set of examples. Honestly, we could use two separate sets of examples: one set to support the motivation, another set to support the specification. Possibly a third set to provide an introduction for people just interested in learning the basics. |
Is the general idea for the PEP to shrink or grow? Or do we not have a rough size target, relative to the current draft? |
I don't care if it grows -- I want it to be accepted. It would of course be nice if it shrunk, but I don't know what we could get rid of. (We could remove rejected ideas that haven't been brought up in the discussion, though perhaps that's because we clearly explained why they were rejected.) There are two pieces of feedback from core devs I'd like to take especially serious: a message (or several?) from Greg Smith where he shows that the PEP confused him (a very experienced Python and C developer) big time; and Mark Shannon's thread about an "Anti-PEP" -- the conclusion of that thread seems to be that opponents might be happier if their view was represented fairly in the PEP. |
We also need a list of acknowledgements. I'd include:
Anyone I'm forgetting? |
I'm sharing a first draft, but I'll work more on these today |
If you check my draft PR, you'll see that it's getting in shape, I'm happy to receive reviews. Mainly what I did is:
I know the PEP is already huge, but I'd like to have an examples section (even if it's one or two, with a link to an external document) to drive the point that a lot of code can be much prettier using this, and describe some concrete applications beyond "walking ASTs" :). |
OK, a couple of status updates on this:
|
It's going to be a busy weekend for me, but I have a few toy examples I have been playing with. I will try to get them cleaned up and open a pull request. They might not be worth putting in the pep directly, a link to the examples in this repo might suffice. |
FYI, this message from Mark Shannon pointed out significant problems with how the introduction is written. I don't believe Daniel has rewritten this part yet. |
This message from Greg P Smith also worries me (especially since I respect Greg so highly). It presents the POV of someone who knows Python (and C, in Greg's case) but doesn't know match from any of the other languages. |
Agreed, I think the PEP misses a great opportunity to explain how
The beginner may not even draw any connection to switch-case / load semantics, when introduced in this way. I still love the |
I also have been reading some of the reactions to the PEP in the python-dev archive. Here are some of my reactions:
We have never claimed that the working prototype will (or will not) be used as the final implementation.
For us, it's a fairly simple mental leap to say "everything between this symbol and that symbol is the reverse of what you would normally expect - destructuring instead of construction." But for someone who hasn't made that mental leap, the fact that everything suddenly behaves the opposite of what they would expect creates confusion and uncertainty. Thus, you see folks calling for extra syntax to signal this different behavior. |
OK, thanks for the awesome discussion. I'll see if I can cover your points better |
I did some drafting myself. I started with an Abstract. I am using Dropbox Paper which is similar to Google Docs but understands markdown. If you have an account you can edit and leave comments. https://paper.dropbox.com/doc/PEP-622-new-intro--A3Izq1j0KV0bBEGm9Fuz6KdBAg-f9Cb9yaOV4olvbeDWG1ML |
I like some of what I see there, @gvanrossum . I stole some of it and added it to my version, including a new section right under the abstract titled Informal overview. The goal of that section is giving the "elevator pitch" and a simple example of the idea, without making the abstract that long. I think it aims directly to tell "this is what's about, and how you read it", likely answering people like Greg Smith that considered this confusing. It also stresses very early on, as @viridia suggested, that patterns are "reverse constructors". |
Going over Mark Shannon's email I think many of the things he didn't like about presentation have been addressed. I still see the following of his points that I haven't covered in my version:
What I'd respond to each of this is...:
|
I'd like to address item 4 on your list. The strict OOP philosophy is that you put logic that deals with the state of an object as a method on the object itself. However, the last several decades have shown a weakness in this approach, which is that it requires objects to understand every possible way in which that object will be used. I have written on this topic in much more depth in my essay, "The Rise and Fall of Object-Oriented Programming". A great example of this is ASTs. AST node types shouldn't need to understand all of the various compiler passes or other visitors that walk the AST graph. For compilers, it turns out that it is architecturally much cleaner to put code for each pass together, separate from the data objects that the pass operates on. It is true that Python has always been a language where OOP was the dominant paradigm, but that doesn't necessarily exclude other paradigms. The I think part of the motivation for wanting match in Python is a desire to explore some of these other non-OOP styles. My Part of the hurdle that we have to overcome is the fact that people are used to thinking in an OOP way, and many college courses and textbooks dating from the 90s taught the rules of OOP in a very strict and dogmatic way. When people see code that is written in a way that violates the rules that they were taught, they might judge it to be a bad design or an anti-pattern. |
@viridia, I agree with everything you just said :) What I'm still not sure is how to put this succinctly and decently argued without turning the PEP into an essay on the comparative benefits of different programming paradigms (writing is hard... ). I'll see what I can do |
Sure (although I wasn't quite done yet -- I was just at a reasonable stopping point to ask for critique). In any case, I will probably stop writing for a while -- my tendonitis is getting worse. |
PS. How I wish we were using Dropbox Paper for the finessing of the text. I've already found a few questionable issues when skimming the rendered version of Daniel's rewrite, but it's too much work to track them down in his PR, so I hope I'll remember then when my elbow is better. |
I could try moving my content into paper... then we can see how to merge it. I'll have to guess some process with Paper (if I don't like something do I just edit? is there a way to "suggest" that can be approved? I just did a fork because the git/PR is a model I'm familiar with :) ). I'll try moving the "Informal overview" section for now, I think it's important and overlaps a bit with the abstract |
Paper emails me whenever someone makes a change (with some delays). If you
see a typo or a slight grammatical issue just fix it; if it looks at all
like different might want to say the same thing differently, select the
text and add a comment with your suggestion.
|
OK, I moved most of my notes here. There was some other stuff in that PR that I'll submit separately |
Also, feel free to just add your work to my Paper doc rather than starting
(yet) another one.
|
I started a write up on how I would introduce this topic to students with some python knowledge. Notably the order I introduce things is different from that outlined in the PEP. I dont know if the lecture style fits well inside the PEP or not, and I didnt want to interrupt others work, so I created it as a stand alone document. If it would be better to be put in the document Guido linked at the bottom, I would be happy to move it there as well. @dmoisset If any of it is useful, you are free to take if for the pep, or it may be useful to link to. I am not finished with it yet, but you can find it here: https://www.dropbox.com/scl/fi/u14yp0msiy9bfmw3mr01m/Introduction-To-Pattern-Matching.paper?dl=0&rlkey=v56lbedzcaafx9xfr4d4vntmg |
Thanks! I would certainly expect that the way to introduce this to students is different from the PEP -- the PEP needs to make the strongest possible argument that we should add this feature and that our design is the best one (especially in the light of the feedback received on python-dev); while the students need the easiest path to understanding how it works (and that path may vary depending on what other parts of Python they already know when you start teaching this topic). |
@dmoisset I did a thorough review of your work in the Paper doc and left you a ton of comments. I also made some small changes directly in the text and used |
The Class pattern is definitely going to be a limitless source of confusion due to the strong association between 'name followed by
For 1. I think the rebuttal is easier: Python already has implicit assignments. In some cases I believe the Runtime Specification should cover this point. It should eventually talk about the when and how of bindings since that's clearly a sticking point for some people. For 2. the situation is trickier. If class destructuring was a thing (as in Rust and, I believe, JavaScript) I'm sure the mental switch between calls and destructuring would be easier. Looking through the PEP (I'm looking at Daniel's branch, maybe I missed it) I couldn't see the rationale behind Though the PEP is getting quite large, a Rejected Ideas on a different pattern for classes might help in making it clear why |
What else looks just like a call but isn’t....? A function definition. (Also a class definition.) |
Well, yes, but those are statements, I was talking about expressions in that specific sentence. And though patterns should not be thought of as expressions I can see how it might be hard for someone to initially make that distinction. |
The top level pattern is preceded by a clear syntax marker, ‘case’. Also, please stop, we have enough people here. |
After python/peps#1500 I propose to post another version to python-dev. I’ll also write a cover letter explaining our response to the feedback. Did I miss any tasks? |
I don't think so. Great effort this week, everybody! |
Thanks for all the help and review during the process. There are a few things that I thing could help make the PEP slightly stronger, which I can submit as a few extra PRs after this land. Some of these perhaps can be saved for emails during the discussion, where presenting ideas is probably as important as "getting the letter of the PEP right". To summarize here what I had in mind:
All of these should be smaller PRs that should be easy to accept or shoot down (so I don't think there are a big delay). I don't want to spam (more) this tracker, but if you give me a thumbs up I can create all of these as issues so we can track them/reject them. |
Thumbs up on all of those, either directly as PRs for the PEP or as iddues in this tracker. If it holds up the posting of the next version, that’s fine. |
The hard part is going to be distilling it down to just a few paragraphs :) |
@dmoisset . The guide to introduce and motivate for those unfamiliar with matching may be useful for your point 3 (either to save you some work or as a secondary link that explains things from a different perspective). I should be finished with a draft what I was planning to write late tonight. I'll let you know so you can decide if it's useful for what you were thinking. |
I added a PR for some of those points in python/peps#1501 . Will continuo on later today |
Added python/peps#1502 and python/peps#1503 ; With @viridia's note and @natelust work on examples, I think I can give a shot to the only other remaining item later today |
Thanks! Now waiting for @viridia to write his piece. |
Landed python/peps#1504. I'm trying to write a piece I can post with the announcement. I'll link it here when I'm ready for review. |
@dmoisset I apologize I didn't get as much time as I thought I would to work on the tutorial paper I linked above. I am traveling tomorrow (prepping for travel in this era took up the time I thought I had) but will be available later in the week to keep working on it (and I'm going to squeeze in time now). You are welcome to take anything from that, or add something to it on your own if you wish. Given my track record on not knowing the best approach to creating examples for this repo I have not opened up a pull request for one of the examples I do have made. If it is useful, you can find an example of using pattern matching to construct objects from rows in database queries here. This example also uses matching for signaling from a function call, somewhat similar to what you would see with returning stateful enums in rust (though they are just classes here). It is based on the chinook example database, and is an application that allows users to list all the artists in the db, or albums and tracts given by a given artist. There is a bit of boiler plate to support the signaling returns, getting, and working with the database, but the match syntax is the heart of it. If this is the kind of thing that belongs here I can take any suggestions and open a pull request. If not perhaps it will be inspirational to someone here. |
Nate, I like your sql example and if you sent a PR I'd add it. |
PR opened, thank you. |
Once within the authors group we have consensus on the major issues (primarily #90) I would like to do a thorough rewrite of the PEP, esp. the rationale and motivation, to lay out the argument much more clearly. We've had a bunch of unfocused negative feedback that comes down to people not understanding the PEP or getting distracted by poorly reasoned arguments and silly examples.
There has also been discussion about an "Anti-PEP" -- this was discouraged by the SC, but basically the people who oppose the PEP want their voices to be heard and I think we should summarize (or ask them to summarize) their main arguments and place them in a separate section of the PEP.
Also, I think the traditional structure of PEPs makes it hard to lay out clearly the arguments for design decisions (by putting everything in a "Rejected Ideas" section). In other languages (or proposals?) I've seen a better structure, where the description of each feature of the specification is immediately followed by a discussion of what the design choices were, how the feature interacts with other features, and and what the pros and cons of various choices are.
Who wants to help with this (ambitious!) second draft of the PEP?
The text was updated successfully, but these errors were encountered: