Mark Shannon wrote: > In future, could you avoid editing emails when replying to them? > A lot of context can get lost.
I'll add another voice to Ethan's saying that I appreciate having as much as possible trimmed. As long as people are arguing in good faith (and I assume that they are here), the loss of context is usually pretty small, and outweighed by being able to find the newly important part more quickly. (I say this as someone reading and replying through the archives, in a way that seems to mangle quoted portions -- but they are usually still good enough to be useful.) > ... Yes, the pattern matching syntax is more concise in some > circumstances, but there still needs to be justification why a > combination of simpler language changes is insufficient. Code that fits on a single small (24x80) screen (without getting too dense) is much easier to understand, because I can see it all at once, instead of needing to remember things while I flip back and forth. A combination of simpler changes might be fine, but shorter really is very valuable, all by itself. > Saves two lines of code, but introduces two bugs! > (Assuming that the original behavior should be preserved) That is a pretty big assumption. I'm guessing that at least one of the "bugs" is that sequences other than the built-in list and tuple are now also accepted. Maybe there are good reasons to exclude other sequences, but ... in my experience, the reason is usually that someone didn't think of it, and no one felt strongly enough to fix it yet. That would mean pattern matching led to a bug *fix*. Closed source code tends to be even more fragile, though it also tends to not see as many surprising input types in the first place. > If you don't have access to the original source, then it can be made a > function, not a method. Even when I have read access, I may not have write access. Creating and naming a separate match function every place I need to match isn't quite boilerplate, but it adds enough code to feel that way. Trying to use a single match function with parameters gets ugly in a different way. I'm not quite convinced that this PEP has found the magic solution, but the goal is clearly worthy. > On 14/07/2020 5:25 pm, Tobias Kohn wrote: > > match response.status: > > case HTTP_RESPONSE.UPGRADE_REQUIRED: > Are you suggesting that all constants live in a separate module? The limit to dotted names is a possibly temporary wart. But even with that restriction, there is no reason you can't gather constants on an object first, and use its attributes. > For a PEP to succeed it needs to show ... > That the proposed change is the best known solution for the > problem being addressed. I think the bigger barrier is "although never is often better than right now," and hope that a better solution will be found later, and fear that backwards compatibility with this would block that better solution. (To be very explicit, I personally abstain on this, because I am not sure whether this is "good enough", nor am I confident a better solution can ever be found.) > I worry that the PEP is treating pattern matching as an ideal which we > should be striving towards. That is a bad thing, IMO. Fair. Like annotations as a typing system, you can personally ignore it if it isn't helpful, but there is still some ecosystem cost. I would like to see more old/new comparisons to judge how intrusive this will be, but eventually there will be (or not be) a leap of faith. In the past, most of those have worked out. > Pattern matching is well suited to statically typed functional languages. and statically typed data domains and communications protocols -jJ _______________________________________________ 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/4S75QY4FVVXW7YGTSFRHEXBK5OXXJM6Y/ Code of Conduct: http://python.org/psf/codeofconduct/
