Guards as patterns

[thautwarm]

Also a track of my communication with Guido.

This issue is to show a reason why it'd be better for Python to have guards as patterns, even though this is not practiced in other programming languages.

In nearly all programming languages with pattern matching, guards are implemented as a special syntax following a pattern(like 'pat if guard =>').

One reason for this is readability, people should coverage in this. However, another notable reason is, those programming languages have AOT/JIT compilers, where putting the guards later helps to optimize instruction pipeline and produce a significant performance gain.

However in Python, we don't have many concerns about instruction pipeline, and further, putting the guards in any place allowing its proper execution, will not affect the performance of Python.

For example,

match expr:
      case C(pat1 if p1, pat2, pat3):
            ...

where pat1 if p1 matches, if and only if, pat1 matches and bool(p1) evaluated to True.

This makes a composite pattern like C(p1, p2, p3) exit as early as possible. Note that it's safe to move the guards as early as possible, this certainly improves performance.

Guido replied that this seems to be a premature optimization. I think we can ENABLE this but do not recommend this in most cases.

However there can be performance critical scenarios when we want to use Python pattern matching.

There can be quite a few examples about machine learning tasks, where pattern matching syntax improves readability and simplicity.

However, without "guards as patterns", some expensive computations cannot get avoided, even though the performance pitfalls are easily observed, and using "guards as patterns" does not affect readability.

[Tobias-Kohn]

There are several issues with this.

One reason for this is readability, ...

Readability is one of Python's really strong suit. I am curious: why do you think it does not matter for us, or that we should throw it overboard?

... those programming languages have AOT/JIT compilers ...

Python has evolved into an entire ecosystem of different interpreters and compilers, such as Jython, PyPy, MicroPython, Numba, Skulpt, etc., all of which have a slightly different approach to how Python code is compiled and executed. You are building your argument here on the assumption that we only have to care about CPython, whereas in actuality we are talking about language features that should work independently of the specifics of a compiler.

This makes a composite pattern like C(p1, p2, p3) exit as early as possible.

Here, you build on the assumption that most patterns fail because of the guards. If the guards are the driving force behind a pattern matching, it is probably time to rethink the design and consider other alternatives instead, such as nested pattern matching, conditionals, etc. The intended use of pattern matching is that it is driven by patterns, not by guards.

We have discussed this quite intensively in different context (e.g., issues #12 and #24).

However there can be performance critical scenarios when we want to use Python pattern matching.

Given the nature of pattern matching, it is hardly the tool of choice if performance is really that critical. Pattern matching is missing a couple of guarantees, but has a lot of freedom and flexibility in return.

There can be quite a few examples about machine learning tasks, where pattern matching syntax improves readability and simplicity.

We fully agree and that is why we actually introduce this PEP. But I have a feeling that you are not really talking about readability and simplicity here, but are alluding to performance. So, again: if you can give a clear-cut example/use case, you might stand a better chance convincing us that there might be a need to reconsider.

[thautwarm]

I agree, fair point.