Match in Python trips up Python parser in tests

[JSAbrahams]

Description of Bug

It appears that the python parser trips up as soon as it encounters a match in Python.
When testing, everything before that is parsed.
We can test this by modifying this in one of the test resources and verify that the associate test fails (assuming we don't modify the associate check resource).
However, if we perform modifications after the match, it fails.

How to Reproduce

Take Mamba file resource/valid/error/nested_exception.mamba:

class MyException1(msg: String): Exception(msg)
class MyException2(msg: String): Exception(msg)

def f(x: Int) -> Int raise [MyException1, MyException2] =>
    match x
        0 => 20
        1 => raise MyException1()
        2 => raise MyException2()

def g() -> Int raise [MyException2] =>
    f(2) handle
        err: MyException1 => print("a")

g()

• Modify anything before the match, e.g. change msg -> msg1, and observe that the test fails by leaving the associate _check.py untouched.
• Now, modify something in match, e.g. change MyException1 -> MyException2.
  Observe how the test still passes despite the output not being equivalent to the associate check resource.

For reference, this is the associate nested_exception_check,py resource:

class MyException1(Exception):
    def __init__(self, msg: str):
        Exception.__init__(self, msg)

class MyException2(Exception):
    def __init__(self, msg: str):
        Exception.__init__(self, msg)

def f(x: int) -> int:
    match x:
        case 0:
            return 20
        case 1:
            raise MyException1()
        case 2:
            raise MyException2()

def g() -> int:
    try:
        f(2)
    except Exception as err:
        print("a")

g()

Expected behavior

The test should fail as soon as the output deviates from the resource.

Additional context

This is a bug in python parser v 0.1.0.
We could update to version 0.2.0, but this only goes up to Python 3.7 it appears.
Therefore, we may need to search for another crate which parses Python files for us.
Furthermore, there appear breaking changes when going from 0.1.0 to 0.2.0, so even if 0.2.0 does in fact resolve the issue, we do need to perform non-trivial changes.

[JSAbrahams]

Perhaps we should fork that crate and see if we can't implement this ourselves