> If the implementation is hard to explain, it's a bad idea.

> If the implementation is easy to explain, it may be a good idea.

Pattern matching is extremely complex, and for what?

Python already has (limited) pattern matching. Example:

    for foo, (bar, baz) in nested_tuple_list:
        ...

This works as expected. The current 3.10 implementation is just half-baked. They should have expanded the existing pattern matching facilities (added support for data structure destructuring).

Presumably then you could just have used the existing walrus operator inside the already existing if-else constructs.

That would have been the obvious path of least surprise. What we got instead seems inadequate.

So you would turn something like this:

    match command.split():
        case ["north"] | ["go", "north"]:
            current_room = current_room.neighbor("north")
        case ["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"]:
            ... # Code for picking up the given object

In to this:

    if (["north"] | ["go", "north"] := command.split()):
        current_room = current_room.neighbor("north")
    elif (["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"] := command.split()):
        ... # Code for picking up the given object

And the walrus operator would assign to 0-many values as required? It kind of breaks it's current meaning and makes the lines very complex, I don't think this version would be more liked...

Yes. The second version is "pythonic" and follows the principle of least surprise.

The first version is certainly cleaner, but introduces, effectively, a new DSL sublanguage.

The second version also effectively introduces a new DSL sub-language, it just puts a walrus operator at the end of it.

I agree the matching is complex, you only have to see what a portion of the grammar file it takes up: https://docs.python.org/3.10/reference/grammar.html

But embedding the match constructs inside existing Python symbols wouldn't reduce the amount of new grammar it would require.

The walrus operator is not the point; the existing constructs should be expanded, that way things make sense and are composable.

E.g., pattern matching of this sort

    for ["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"] in list_of_get_commads:
        ...

IMO should have "just worked".

But now we have two different and incompatible versions of pattern matching in Python.

That's not an existing construct, it's a LHS assignment language like the match statement but it's embedded inside a for-loop.

Which means you have to implement all the grammar of the current match and it restricts to only works on iterables.

How would you implement this for an object that isn't iterable?

The example is misconceived to begin with? Why are you hard coding an interactive fiction game in Python? You should make an interactive fiction engine, of which there are already a million examples, and then write the script in a language made for IF, not Python.

I took the example from the PEP itself, feel free to list out a different one.

Appealing to nothing but the zen of python is not an acceptable argument.

Pattern matching is not (necessarily) extremely complex as it exists in a multitude of languages these days. Powerful does not automatically imply complex.

Acceptable to whom?

Anyhow, read the PEP. It is an extremely complex new language feature.

To many in the core team, for one. It’s a cutesy easter egg at best not a mission statement.

I’ve read the pep. The nature of peps are complete by design. The concept is not overly complex especially since it exists in a number of other languages.

I would say it's much more powerful than switch-case, but it's only moderately more ergonomic than elif. The reason for the former being that switch-case only ever checks exact equivalency; if you need to do anything slightly more nuanced, you have to bail out to something more flexible.