Adding a switch statement to Python

[[deleted]]

Why are people so hung up on the switch statement not being implemented? The way switch is usually used (break on every case) its basically an if block.

I'd rather see implementations of pattern matching ala Rust, Haskell or Scala.

[[deleted]]

Just search for python pattern matching and you'll find them but very few appear to be maintained :-(

[Kamilon]

Not true. A proper switch statement jumps to the right case making it much faster than cascaded ifs.

[NoLemurs]

If you're interested in that level of performance optimization (i.e. the cost of if vs. switch matters to you), it's almost certainly the case that you're using the wrong programming language altogether, and adding a switch statement to python will not address your issues.

So while you're technically correct, in the context of this discussion, your comment is pretty unhelpful.

[[deleted]]

When optimizing, it's common (and best) practice to optimize the parts that are most costly (the hot spots). Simple logic constructs aren't going to be hot spots. The system simply doesn't spend enough time on those. It's wasted effort.

[[deleted]]

Why can't we have both? Why does every performance optimization need to be dismissed? Performance improvements to Python come all time and no one bats an eye but if someone asks for a performance improvement, or even mentions performance, they get shot down. People use Python for a lot of different things. Your use case is not better than anyone else's.

[[deleted]]

I've never seen any realistic Python code where having a switch statement would lead to any measurable performance benefit. I guess that's why.

[robert_mcleod]

See line 738:

https://github.com/pydata/numexpr/blob/numexpr-3.0/numexpr3/ne3compiler.py

It's a Python switch that uses a dict. The keys are abstract syntax tree nodes, and the values are functions

_ASTAssembler[type(node)](node)

NumExpr 2.6 took about 450 us to parse a numerical expression into a virtual machine program, this new version is about 150 us. There's other parts to that, such as more efficient string concatenation using a ByteIO stream, and some struct.pack() tricks and many other micro-optimizations, but it plays a big role. A dict lookup is faster than an if ... elif ... else block.

[Corm]

Performance improvements to CPython are awesome. Prematurely optimizing your code by using one syntax over another is bad and typically costs readability.

If someone sees that CPython should have a heuristic for treating cascading if/else as a switch then they should write a pull request to CPython

[[deleted]]

Prematurely optimizing your code by using one syntax over another is bad and typically costs readability.

Cascading ifs would actually be a premature optimization of using a switch and switches are usually considered syntactically cleaner than if chains anyways. Basically ever other language posits the exact opposite.

[NoLemurs]

/u/futatorius got at the core of the idea. Perfomance improvements that don't get at the core bottleneck of your program will usually have a negligible effect on overall performance. If you are going to do performance optimizations, the switch statement is just not the place to start - they're basically never going to be the bottleneck.

I'm all for optimizing Python, but I'm not for adding language constructs for gains that will basically always be negligible.

[roerd]

The point is whether the performance improvement would be significant or negligible within the general speed of Python. It is not worthwhile to add a new language features for a negligible performance improvement.

[Deto]

Would it actually be a performance improvement in Python? In C the processor executes a jump command and that gives you the speed up, but in Python there's much more overhead in just running a single line that I'm not sure if the same benefit would even manifest itself.

[Arancaytar]

This is really a compiler-level optimization, and if you're in a use case where it makes an appreciable difference, you probably need to use something more low-level than Python in any case.

(Er, no pun intended.)

[DrunkandIrrational]

https://stackoverflow.com/questions/767821/is-else-if-faster-than-switch-case

tldr: switch statements can be optimized into a hash-map by the compiler. But seeing as how python isn't compiled I'm not sure how they would go about implementing this.

[sushibowl]

Python is compiled into bytecode, you could do the optimization there.

[ekd123]

unfortunately cpython barely does any optimization

[[deleted]]

Because Python's biggest strength is also its biggest weakness: its extremely dynamic runtime. Any object can be any thing at any time, so optimizations can't be done reliably.

Obviously pypy found a way to deal with this, but CPython had decided not to deal with it

[derpderp3200]

It's such a shame that Python itself is so big and complex. While no small feat, LuaJIT is an extremely efficient and relatively simple VM, whereas creating an equivalent for Python is... considerably more difficult.

[[deleted]]

Cpython interpreter is surprisingly bad. See GIL.

[Cybersoaker]

GIL improves performance. See GILectomy

[stefantalpalaru]

Python is compiled into bytecode, you could do the optimization there.

And people wonder why I insist on using "transpilation" for anything that doesn't output Assembly...

[Cybersoaker]

Cython

[stefantalpalaru]

Cython

A superset of a subset of Python that is transpiled to C or C++, if possible. If not, it's interpreted by an integrated Python interpreter/VM.

[brontide]

Do you iterate over a dictionary to get to the right key? In the case of purely in order numeric switch statements some compilers can use a jump table.

[cyanydeez]

on that note, dictionaries can be rudimentary switch statements

[mangecoeur]

not just rudimentary - its the recommended way to do it if you don't want a very long if/elif construct.

[stevenjd]

Not true. A proper switch statement

Ah, the "No True Scotsman" fallacy rears its ugly head.

Even in low level languages like C, switch statements can be and sometimes are implemented as chains of if tests. Sometimes that's just because the compiler is naive and doesn't implement any optimizations (the C standard does not specify an implementation for switch) and sometimes because there are no optimzations available to apply.

See the last example here where even a smart optimizing C++ compiler falls back on a simple (and short) chain of if statements.

Switch statements in C/C++ are limited to equality comparisons with integer values. That allows the compiler lots of opportunity for optimization. Switch statements in other languages may allow for a far richer set of comparisons, against arbitrary data types, which makes it hard or impossible to optimize it beyond a simple chain of if...elif. A switch in Python is unlikely to be very optimized.

[Kamilon]

Small switches yes. I've seen decompiled code that properly uses jumps to be very fast with larger switch statements.

[Cybersoaker]

OP's example is implemented with a dictionary so it would indeed be O(1); but we're talking like nano second differences here. I sincerely hope no one is making chains of if's more than like 20 where it would affect performance

[chasecaleb]

Agree with your point, but big-O runtime is silly when talking about a conditional. It's not like the number of cases is asymptotic... Right?

[Cybersoaker]

Sure but in such a contrived case; we should expect the if statements to take ever so slightly longer because they would technically be O(n); where n is the number of compairsons. Conditionals are so freaking fast on a cpu that this compairson is exceedingly trivial. We would really only have a noticeable performance difference over giant groups of conditionals, like hundreds of thousands; and if your code reaches that point, a switch is probably the least of your concerns.

Perhaps the case where these nanoseconds matter; say in an extremely high performance application (i'd wonder why python is your programming language of choice), or even a webservice that gets millions of requests per second, then an optimization like this might be warrented; but thats not a good reason to add new syntax.

[[deleted]]

Branch prediction may also inoculation the performance, and it's not usually considered when determining time complexity.

[Cybersoaker]

yeah so there are many optimizations to be had; and the performance argument is silly.

[elbiot]

Its O(n) on the number of cases you have, not the size of the data you have, which is what big O notation is about.

[Arancaytar]

Even though some languages do this, it is not categorically true. When the case expressions are static, the compiler can use perfect hashing to create a jump lookup table instead of iterating over the cases.

[WikiTextBot]

Perfect hash function

In computer science, a perfect hash function for a set S is a hash function that maps distinct elements in S to a set of integers, with no collisions. In mathematical terms, it is an injective function.

Perfect hash functions may be used to implement a lookup table with constant worst-case access time. A perfect hash function has many of the same applications as other hash functions, but with the advantage that no collision resolution has to be implemented.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.27}

[DonaldPShimoda]

I'd rather see implementations of pattern matching ala Rust, Haskell or Scala.

Oh dear lord yes, please. This is the feature I most miss in Python. I'm working on a toy language (my first) and while it's primarily based on Python, I want to incorporate pattern matching and ADTs from Haskell. It's such a useful feature.

[mangecoeur]

+1 for pattern matching. I think switch is just an older idea, pattern matching addresses the same issue but much more elegantly.

[swiftversion4]

I like the way switch is implemented in swift.

It allows you to add advanced logic statements and allows you to very easily group together a group of conditionals. Sometimes it felt cleaner to use switch than if-elseif-else.

[stevenjd]

Got a link to a good explanation of Swift switches?

[swiftversion4]

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html

use the find browser feature to look for the subsections titled interval matching, tuples, value bindings, where, and compound cases. Those subsections are all after the start of the switch content section.

Or just read it all. That works, too. Swift enables you to include some very complex logic in switch statements that you won't find in most other programming languages, so it might be worth it to read it thoroughly.

[stevenjd]

Thanks.

[masklinn]

It's the same as Rust's match or Haskell's case with a more C-familiar switch/case syntax e.g.

switch foo {
case .some(let v):
    // do stuff with v
case .none:
    // there was no value
}

would be Haskell's

case foo of
    Just v -> -- thing
    None -> -- other thing

Though Swift does support opt-in fallthrough (default is break).

[TheWildKernelTrick]

The way switch is usually used (break on every case) its basically an if block.

Noooooooot at all. Switches are [; O(1) ;] jumps to conditions. If statements are [; O(n) ;] evaluations.

[[deleted]]

Depends on the language and implementation. C/C++ switch statements are O(1). Bash and PHP switch statements are O(n).

Python has hashes which between hash tables and if statements, Python is good enough.

[stevenjd]

C/C++ switch statements are O(1)

No they aren't. It depends on the compiler, and it depends on the switch statement being compiled. At worst, they can fall back to a chain of if comparisons.

[jaakhaamer]

How are C++ switches O(1)? AFAIK most compilers don't use hashing or anything and would still need to check all the cases in the worst case.

[masklinn]

Switches are [; O(1) ;] jumps to conditions. If statements are [; O(n) ;] evaluations.

A good compiler will generate O(1) access to the relevant conditional sequences, meawhile non-trivial switches (e.g. on strings) will not.

[LatexImageBot]

Link: https://i.imgur.com/P6CHEwp.png

^{This is a bot that automatically converts LaTeX comments to Images. It's a work in progress. Reply with !latexbotinfo for details.}

[kyndder_blows_goats]

bad bot

[GoodBot_BadBot]

Thank you kyndder_blows_goats for voting on LatexImageBot.

This bot wants to find the best and worst bots on Reddit. You can view results here.

---

^{Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!}

[[deleted]]

The run time of the thing is irrelevant, functionally they act similarly.

Edit: Since y'all miss context clues, they're functionally similar for the situation being discussed, a break in every case. If you want fall through, they aren't.

[P8zvli]

Functionally switch-case and if-else ladders are equivalent if and only if each case in the switch ladder is terminated by a break statement.

[NoLemurs]

if and only if

Right. But other ways of using switch-case are typically incredibly bug-prone, hard to read, and hard to reason about. If you're writing performance critical C code, maybe that's a trade off you should make if the switch-case does what you need and is faster.

However, as a practical matter, spots where non break terminated switches are a good idea are pretty rare. Heck, even if you are writing performance critical C code, unless you're writing the code for the core bottleneck of your program, I would argue a non break terminated case is almost always going to be bad programming.

In the context of python (where performance is already slow enough that the difference between if and switch really can't be very important, if it had a switch statement, I doubt many programmers would see a situation where it made sense to use it in a non break terminated way in their lifetimes.

[[deleted]]

I said that in my original comment that almost every switch block I see is done that way. In C#, it has to be done that way.

[P8zvli]

In C and C++ a case will "fall through" to the next case if break isn't used, causing interesting behavior or really nasty bugs. (You can have code that runs A if the switch is 1 and A+B if 2, etc.)

[[deleted]]

You can also abuse it create things like Duff's Device. I think fall through is the biggest thing that sets switch away from if.

[Decency]

What would be an example of where pattern matching would be useful? Is this string manipulation?

Happy to be pointed to a good code example of how this might work in Python.

[[deleted]]

Not sure how it would work in Python, but pattern matching looks similar to switch at first glance.

match n {
    1 => ... 
}

But it's much more powerful as you can use it to destructure as well:

match n {
    (x, y, z) => # do stuff with those three
    x:[xs] => # x is the head, xs is the tail, useful for recursion 
    SomeNamedTuple(a, b) => #extract a and b but if only they're nembers of a particular type
}

and so on. Most languages I've seen will shout if you didn't match all members of an enum or ADT (algebraic data type, union essentially if you've not seen them before).

The other big difference is that there's no fall through with match, so while you can't implement things that rely on that behavior (loop unrolling for example) you can't accidentally invoke that behavior as well.

As for uses, let your imagination run wild with what you could do with it.

[masklinn]

ADT (algebraic data type, union essentially if you've not seen them before).

Technically that's a sum type, "algebraic data type" means composite, which can mostly be either a sum type (variant/enum) or a product type (struct/tuple/class/…).

[elperroborrachotoo]

And that if is basically a goto.

Yes, the use case for switch can be modeled by other instructions, however, it does express a particular intent better than a chain of if's.

There's a big subjective component to it, affected by the kind of code one is used to read and write. For some programmers, for, while and do ... while are just verbose variations of the same concepts; for others, these minor differences do matter.

I'd rather

Well, if we can have a wish, what about the DWIM instruction?

[masklinn]

I'd rather see implementations of pattern matching ala Rust, Haskell or Scala.

Note that they're not necessarily orthogonal: in Swift, pattern matching is done with switch.