User-defined patterns about patma

[Tobias-Kohn]

I think this feature is somewhat problematic and probably superfluous, and would therefore vote against it.

Problematic because of value extraction/variable binding. As your question already indicates: what happens if the user-defined pattern should bind a value to a variable? How is that properly and correctly propagated to the surrounding context? It is a bit like defining a new local variable using exec/eval. Moreover: who would have knowledge of the name and nature of the extracted variable? In other words: what kind of code would be aware that the pattern has matching something and bound it to a variable x, say?

On the other hand, if we say that a user-defined pattern cannot bind to a variable, but would match against a variable, it can suddenly access variable values of the surrounding context, which is where I see a potential security risk. Actually, allowing a user-defined pattern to write to a local variable is probably likewise a very bad idea from a security point of view.

If the example is just as simple as comparing numeric values, you can use guards and simply do case v if v == P1: without the need for user-defined patterns in the first place.

Finally, yes, the mechanisms discussed in issue #8 with a __match__ method would allow to easily write something like a customised, user-defined pattern if really needed. So, there is actually no need to support something like this on a language level, as it could easily be done by a library (and in a more controlled way).

In a way, I would argue that pattern matching is actually not purely runtime behaviour, exactly because of variable binding. I see it more akin to how local variables behave: while an assignment to a local variable is runtime behaviour, indeed, the compiler determines statically whether a variable is local or not.

[gvanrossum]

Agreed. I was probably excited having implemented a bunch of objects that represent the basic abstractions for pattern matching (see file "patma.py" here). But I've since come up with an alternative way to translate patterns into code (see various translate() methods) and there it would be inconvenient to have to support this.

[gvanrossum]

Something like this has come up in https://mail.python.org/archives/list/[email protected]/message/DDYISJOZPJOD2C2RY4HH2XS3YMHBVYWX/

[Tobias-Kohn]

Yeah, I saw the post. As far as I understood it, Federico Salerno's point of this is to solve the lead/store issue. To that end, he is basically proposing a somewhat cumbersome implementation of proxy objects with quasi-scopes, rather than binding local variables as in the current PEP. To be honest, I feel that if we really boil down his proposal in that post, most of it just evaporates and leads to basically the same discussions as we already had.

[gvanrossum]

Yeah, his proposal is the same as my poorly conceived idea here. But I feel it still needs some kind of rational response, since it's bringing up a new idea (for the list) rather than rehashing something old (like different sigils or keywords to mark loads or stores).

Though maybe we needn't respond until at least one other person supports his idea (this has roughly been my approach).