Sorry I don't have the code but I thought elfi and kllr might be interested.

Well, well, well, sounds like I was right after all, then!

There is no switch statement because Guido is doesn't want them in python. A lot of people want them, and there is really no good reason why not to have them, but Guido says so.

It's more that nobody has shown why you need them - just because people want it doesn't make it a good addition. Switches tend to be rather verbose syntactically and they are very rarely a good solution to whatever problem you are having. This is why Java totally half-assed switches, for example.

The only argument I've ever heard against them is that the default behavior of falling through is confusing. There are several possible responses to that -

• It's not confusing at all once you understand that switches are stand-ins for indexed branch tables which pack the code segments end to end, so that falling through is the natural behavior to expect.
  
• If you're designing a new language and it bugs you, just make breaking the default behavior, and require a "continue;" to fall through. I wouldn't do this, since I think fall through is quite sensible when you understand what switch statements are for, but I wouldn't be horrified by someone who did, either.
  
• And my personal favorite: Don't be stupid, pay attention to the code you're writing.
  

Switches generally suggest the use of indexed jump tables, which are almost always more efficient than the straightforward implementation of if/else constructions as sequential conditional branches.

On top of this, there are a number of cases where fall through provides methods of cutting back on code repetition that would be significantly less straightforward with if/else (which was the motivation for my original post in this thread).

Suggest, but don't necessarily use - and for interpreted languages like Python, almost certainly won't use indexed jump tables or be efficient anyway.

Besides, that's the compiler's problem, not mine as a developer.

That's a good indication you should be using methods or classes, not more code inside a single control structure.

I wouldn't even mind a language that allowed you to optionally specify your own hash function to use with its switch construction.

Software developers who don't care about complexity are the root of all evil. A compiler's job should not be altering the asymptotic complexity of your code.

Why on earth would you want that? So you can spend more time in the hash function than doing a small handful of ifs?

Your argument for switches hinges on the compiler altering the complexity of your code - so good job being hypocritical there. A switch is still multiple ifs, and most often implemented as multiple ifs. It *can* be made into a jump table by the compiler, just like if/else if/else if can also be made into a jump table by the compiler.

O(1) vs. O(N) when N < 10 also isn't all that significant.

Optimizing for O() is misleading anyway - computers aren't the ideal machines big O notation assumes.

And let's make one thing clear since you seem a bit confused, switches are only faster than if/else if *IF AND ONLY IF* they get optimized as an index jump table, which doesn't happen as often as you think. Only happens if your using ints and those ints are consecutive

which will happen exactly never in Python ('int' is a class/object, not a primitive),

and pretty rarely in most circumstances anyway.

To give you control to make appropriate decisions based on the scenario. There are many hash functions you could write that would take hardly any time at all to execute, but which a compiler might not be smart enough to figure out.

No. A switch, abstractly, is a multiway branch, in some cases the compiler doesn't know how to implement as such concretely, and must then fall back on sequential branching.

because nobody ever writes switches with a large number of cases?

O RLY. I'm pretty sure big O notation doesn't assume an "ideal machine", just "for n large enough". Cases where O() really would be misleading for reasonable n (1.0000000001^n vs n^100000) pretty much don't show up.

False. There are a good number of cases where the compiler can fall back on a O(log(n)) tree jump table before it has to fall back to sequential access.

I'm not sure how this is relevant. Python int's are still well-ordered.

We can keep arguing if you want, but it's not terribly likely you'll convince me to side with Guido van Rossum over Donald Knuth and Peter Naur.

Abstractly, yes, but in reality it's just a series of if/else ifs because CPUs don't have a "switch" style instruction.

No, they assume there's no such thing as caches, branch prediction, and that all operations magically take the exact same amount of time.

I cannot find a shred of evidence of this hypothetical tree jump table, care to actually back that claim up with anything at all?

Because you can override equals, and more importantly you can replace equals on specific instances of int. You can't do jump tables if you don't know how the compare works.

Donald Knuth and Peter Naur? Where have they published their feelings on switches, and Python's lack of them?

Multiway branching is an important programming technique which is all too often replaced by an inefficient sequence of if tests. Peter Naur recently wrote me that he considers the use of tables to control program flow as a basic idea of computer science that has been nearly forgotten; but he expects it will be ripe for rediscovery any day now. It is the key to efficiency in all the best compilers I have studied.

Caches and branch prediction usually improve the use of big-O as a measure of complexity for moderately sized n (i.e., they diminish the size of the constant factors being ignored). As long as all instructions take a constant amount of time, the CPI variation is going to be not terribly relevant to large n. Let's say addition takes 5 cycles, and division takes 100. An O(n^2) algorithm that calculates the sums of all input pairs is going to be slower than an O(n) algorithm that divides each input by the next for n>20.

I've stepped through them in GDB before (after having disassembled a program compiled from C), and I know the JVM provides an O(log(N)) lookupswitch instruction as well as an O(1) indexed switch, and NEVER resorts to O(N) (so much for "Java totally half-assed switches"). And apparently C# produces CIL that might be any one of the three (but not favoring the O(N) implementation except for small N).

I'm still not sure how this is relevant to a claim that "you can't do switches with Python ints".

Not python specifically, but

If your switch has 20 cases, you're code sucks and you're doing it wrong.

That's also still not a tree, so again - back that up y0.

Stepping through it does not mean the compiler produced it. Nesting switches are a common optimization if you want to do a switch with a group of common cases + a group of uncommon cases.

How people use computers, how we program them, and how they are implemented have changes just slightly during the past 40 years.

You can't do them with preserved locals, but neither of those two argued specifically for that.

Just because you program for cellphones, which only have 15 or so keys, doesn't mean nobody else needs to handle big-boy keyboard input ever.

Which is to say, a sizeable percentage of software engineers have turned into lazy a who are unconcerned with effective use of their hardware, on the assumption that it's fast enough and smart enough to allow them to get away with anything.

No, that's just good language design.