On 07/14/2020 11:05 AM, Mark Shannon wrote:
On 14/07/2020 5:25 pm, Tobias Kohn wrote:
On 07/14/2020, Mark Shannon wrote:
In future, could you avoid editing emails when replying to them? A lot of context can get lost.
I appreciate posters who take the time to trim the parts of an email that they are not replying to.
Why the use of "shape" in "scare quotes"?
Because the `shape' of an object is not something that is a well-defined term, but rather addresses the intuitive understanding to explain what we are talking about. It is usually the intention of the abstract to give a rough overview, before delving into the details and more formal descriptions.
You ignore my point about explaining PEP 622 directly. Sure, the abstract must give a high level overview, but it should be able to do that without so much hand waving.
I find the PEP abstract concrete enough. Perhaps you could write a replacement that you think does a better job?
Actually, no. Pattern matching is not about _avoiding_ anything, it is about a more concise syntax. The suggestion that we wanted to avoid calls to `len` or `isinstance` is similar to the idea of using a lambda to avoid a function. The objective of pattern matching is to introduce a more succinct and readable way to express structure. It's all still there but we want to focus on the structure rather than `isinstance` calls.
I should have been clearer. Avoiding *explicit* calls to `len` and `isinstance`. 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.
My apologies if I missed it, but do you have some ideas of these simpler language changes that would do the job?
Pattern matching already exists in some limited way in Python. Even today you can write: `a, b = value`
I think most of us are aware of unpacking in Python ;)
Yes, but not everyone recognizes that unpacking is a form of pattern matching.
instead of: `a = value b = value`
The idea of this is, of course, not so much about avoiding item access, but about having a more concise syntax for it. Moreover, saying this only saves a single line and is therefore rather useless is quite beside the point. It is about a better representation of what the code is supposed to do and not about saving lines.
How do you quantify "better representation" then?
You mean, without large study groups and lots of money and/or time? Not easily.
I can tell you that
a, b = value
is much more informative, and easier to read and process, than the alternative of using item assignment.
Saves two lines of code, but introduces two bugs! (Assuming that the original behavior should be preserved)
Thank you for pointing out the bug in our example. This highlights, however, rather the difficulty of refactoring (did I already mention the issue of the 'context' that real code is embedded in?), than any shortcoming of pattern matching as a tool. And by the way: constructive critisism would perhaps include explicitly naming the two bugs.
I'm not sure it would be more constructive, this is not a bug report or code review after all.
It should be. If the PEP is to be decided on it should be as correct as possible.
The point I am making is this: It is far too easy to make mistakes using the constructs proposed in PEP 622.
You're point is false. They weren't crafting new code, they were refactoring.
For example, by adding a simple "matches" method to Node and Leaf, `is_tuple` can be rewritten as something like:
This assumes that you have full control over the entire code. But if you are using some third-party library, you cannot "simply add a `matches` method" (without some substantial trickery). Moreover, there is quite some work needed to define such a `matches` function as you propose it (including support for the ellipsis as wildcard). In effect, you would have to implement large parts of the pattern matching for just this simple example. Whereas we believe that it has merit enough to have the compiler do it for a wide range of possible use cases.
You wouldn't have to implement large parts of the pattern matching, because this would be specific to one class. There are only two or three cases to deal with. If you don't have access to the original source, then it can be made a function, not a method.
So, a few lines for that example, another few for a different example, some more for that example over there -- how many times do we have to write similar code before we let Python do the grunt work for us?
Preventing the use of symbolic constants or other complex rvalues is a impairment to usability.
First, let me quote what the PEP has to say on that exact example:
Although this will work, it's not necessarily what the proposal is focused on.
So why does the PEP include it as one of just three examples?
To show that it is possible?
The PEP needs to convince us that it is a useful tool.
Or we can look in our own code and see where it would be useful. I was able to find a location within only moments of searching, and I even managed to get the refactoring correct.
Providing compelling real world examples is necessary.
I found the examples provided very compelling.
Pattern matching is well suited to statically typed functional languages. Python is, at its heart, a dynamically typed procedural language.
And this PEP will finally give us pattern matching for our dynamic language.
Higher-level more declarative programming is great, but there are many ways to do it. List comprehensions, dataclasses, and f-strings are examples. Each of those adds a clear benefit without being overly complex. It was also clear what code patterns they streamlined.
PEP 622 fails to make clear which code patterns it streamlines.
I found it very clear:
- lots of conditions to see if you have the object you think you have? Use Pattern Matching.
Think of it perhaps this way: pattern matching is like introducing grammars and parser generators instead of writing a new parser each time. It answers the question of: could we have something like regular expressions for graph-like objects instead of only text...?
Objects are about encapsulation. They may be graphs internally but that should be hidden. Objects should be able to provide an interface without exposing their internals, which means you can't efficiently pattern match on them. Pattern matching is for Algebraic Data Types, not Objects.
Pattern matching is not enabling us to check for anything we weren't already checking for, it's just making it easier to see what is being checked for. And since everything in Python is an object, and a working implementation of pattern matching for Python now exists, I would say pattern matching is definitely for objects.