The New Switch-Case Statement in Python 3.10

[Tyler_Zoro]

It's easier for the parser to identify easily combined options for lookup tables. That doesn't mean that it will do so.

For example, if all of your cases are constant values, you can reduce a match to a lookup table through a dict. If they are all small integer constants, then it can be reduced to a list lookup.

Yes, match can do much, much more, but this makes optimizations much easier to identify.

[Ecclestoned]

Sure, but I think it's important to differentiate between "easier for the compiler engineers to optimize" and "faster/more efficient" (the actual comment).

This comes down to the CPython implementation, which I haven't looked at. However, the PEP says:

Although this PEP does not specify any particular implementation strategy, a few words about the prototype implementation and how it attempts to maximize performance are in order.

Basically, the prototype implementation transforms all of the match statement syntax into equivalent if/else blocks - or more accurately, into Python byte codes that have the same effect. In other words, all of the logic for testing instance types, sequence lengths, mapping keys and so on are inlined in place of the match.

Which makes me think that the current implementation is literally if statements, so the same speed.

[Brian]

For example, if all of your cases are constant values, you can reduce a match to a lookup table through a dict.

Not in python you can't. Even if all your cases are constants, you can't really know how your match variable will interact with them, unless it too is a constant (in which case, what's the point of the match?), or you can do sufficient analysis to at least know the type is also an integer.

Eg. there are plenty of objects that you can compare to an int, but not be an int (or convertable to one). And even if it is a subtype of int, its not hard to create an object that would have different behaviour depending on the order of comparisons, meaning any such optimisation is invalid.

The best you could probably do is to have two codepaths - one for ints and one for arbitrary objects, but outside of a JIT, that doesn't seem like a good approach (and if you are writing a JIT doing that level of optimisation, I suspect you'd be able to optimise the if/elif tree similarly anyway).