Python Switch Statement | Hacker News Reader

Python Switch Statement

matteoguadrini.github.io

27 pointssticazzii35 comments

Actually Python will (probably) support switch, it will be called "match" and it will be better than switch (think Rust/Scala/F# match or C# switch): https://www.python.org/dev/peps/pep-0634/

It was discussed on HN: https://news.ycombinator.com/item?id=26080760

So, maybe there is need for switch - some people think the language will be better with the match statement.

I would be more careful about comparing "match" and "switch". If people assume that the match operator is a switch operator, they will not be able to explain the difference between these two behaviors: https://news.ycombinator.com/item?id=26082225.

I get it that you can use "match" as if it were a "switch", but I think it's important to drill in every Python developer's head that they are not the same thing.

This is the bad part of Python's match, I don't understand why they want to do it this way - in neither Scala, Rust, F#, C# you'd would (AFAIK) hit such issue. For example C# example of both behaviors: https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBQMwAJboMLoN7LpHoDG...

I don't know about those other languages, but Rust needs static type information to solve it (which Python doesn't have). Take this code:

  static NOT_FOUND: i32 = 404;
  match 403 {
      NOT_FOUND => println!("Not found"),
      _ => println!("Other"),
  }

It doesn't compile:

  error[E0530]: match bindings cannot shadow statics

It does compile if you change static to const (and then it does what you want).

But if you misspell NOT_FOUND so it doesn't shadow a static then it misbehaves in the same way as the Python version, with only a few warnings to show for it.

Python has the limitation that there's no fundamental difference between ordinary variables and constants.

I don't know of an alternative proposal for Python that isn't burdensome or also dangerously surprising.

That C# example is so much nicer than Python’s approach of casually breaking fundamental programming principles [0]. I wonder why Python’s designers didn’t use something similar?

[0] https://twitter.com/brandon_rhodes/status/136022610839909990...

Python didn't handle enumerations, either, until around 2.6 (?) when they were added as a module.

The match operator (I guess the new keyword means it can't be a module) seems to be a similarly well-considered additon to the enum.

Python appears to add common features after more front-end work than the competition.

That said, one fears the higher release tempo could lead to "featuritis". I still have yet to wield the walrus operator that was recently added in any code.

I think these arguments about whether language X “needs” a switch statement are asking the wrong question.

The right question is, “Is language X better for having a switch statement?”

Very few control structures are strictly necessary because it is almost always possible to achieve the same thing in a different way. For example, in C, you could rewrite this:

    while (x < 10) {
        // ... some code ...
    }

To this:

    goto test;
    begin:
    // ... some code ...
    test:
    if (x < 10) {
        goto begin;
    }

The fact is, there are important differences between a map full of objects and a switch statement. One IMPORTANT difference is that if the switch branches contain references to variables the outer scope, then to convert the switch into a map, you have to construct the object at least once each time you enter that scope, and the cost of constructing it is proportional to the number of branches. Similarly, if you use a chain of if/else statements, then the cost of finding a branch selected uniformly is proportional to the number of branches.

With a switch statement, there is normally some kind of assumption that the compiler is capable of optimizing a subset of these use cases—often a well-known or well-understood subset, and that the switch is fast—perhaps similar to a dictionary lookup or table lookup—yet without the cost of constructing a closure for each branch. Even a novice compiler developer can figure out how to make their compiler generate a table for integers or strings.

“I’ll just make this control structure out of lambdas” is something that’s theoretically sound, but which may require a much more sophisticated set of optimizations to get similar performance out of.

This is not a hypothetical concern—if you want to implement a lexical analyzer or parser, you often want to build it out of big switch statements, especially if the switch statements can be transformed at compile-time into table lookups or something similarly fast. The cost of parsing data, in my experience, can often be a significant fraction of the runtime of the entire program.

(If your response is, “Well, why write a parser in Python if you want it to be fast?”, then, well, keep in mind that CPython is not the only Python, and there are many reasons why you would want to write a parser in Python otherwise.)

You can just lift the objects so that they are a function of the scope so that the table of them only need to be constructed once.

Python (C) does not have the tabled indirect jump that would be required to convert the table of objects into a table of offsets thereby turning the function call into a jump.

The compiler could use such a tabled indirect jump for every switch statement. Some of which could be optimized by using a different type of table rather than always using a frozendict.

> You can just lift the objects so that they are a function of the scope so that the table of them only need to be constructed once.

So, I had very carefully worded that statement. I said you have to construct them "each time you enter that scope."

Although CPython does not have a jump table opcode, it easily could, if it were a priority.

I might not have understood it correctly. I thought you were thinking of:

  def bar(x):
      def X(): return 1
      def Y(): return 1
      def Z(): return bar(x-1) + bar(x-2)
      table = {0:X,0:Y}
      default = Z
      return table.get(x, default)()

Whereas I was thinking of:

  def X(x): 
      def X(): return 1
      return X
  def Y(x):
      def Y(): return 1
      return Y
  def Z(x):
      def Z(): return bar(x-1) + bar(x-2)
      return Z
    
  table = {0:X,1:Y}
  default = Z
  def bar(x):
     return table.get(x, default)(x)()

Which can be reduced to a tabled indirect jump:

  def bar(x):
      jump by x via table T and default D where T = {0:X,1:Y} and D = Z
      X:    return 1
      Y:    return 1
      Z:    return bar(x-1) + bar(x-2)

In the future, Python will have every available language feature possible, the maximal set of non-contradicting features capable of existing under the same roof, pulled from every language to exist more complex than Brainfuck. And should have expanded to at least nine different ways to format print statements.

Made me chuckle. Not because you are wrong but it reminded me of the number of people who don't see python for what it is, like you correctly did. Python is NOT a prescriptive language. It is designed to be used and massaged in many different ways. Devs form opinions on what their favorite ways are. Consistency in code is really up to standards set by the team bland not by the language.

One of the easiest way to identify a novice programmer is one who has very strong opinions about "the one" way to do things. Any deviation and their blood pressure starts to rise.

Anyway, your post was amusing.

> Python is NOT a prescriptive language.

It started out as one. Anyone remember the Zen of Python?

> There should be one-- and preferably only one --obvious way to do it.

I think that pep is as obsolete as 20th century itself.

Wellllll ... there are two lines in the Zen of Python that I think about here: "Special cases aren't special enough to break the rules." and "There should be one-- and preferably only one --obvious way to do it."

I fled Perl. I did so for numerous reasons, but perhaps the most frustrating was that there were so many ways to do something, and trying to standardize on an idiom was frowned upon, given "TMTOWTDI." This, in practice, is a contributor to Perl code requiring more cognitive load to read and translate into "What was the programmer trying to do?" Other factors added in, of course, but Python was comparatively obvious at the time: you look at the line, it is clear what is going on.

As the number of language features in Python expand, Python as a culture must rapidly settle the "idiom" or lose the "obvious way." Just how many flow control statements do we need? Obviously there is a bare minimum for Turing completeness, and beyond that a sweet spot.

But I fear that Python may slowly become a kitchen-sink language with no idioms, and so coders would be reduced to some of the downsides of Perl.

Myself, I try not to have opinions about how to do a particular thing so much as I care about that there is a settled way of doing it. The more ways that are common, the more choices I have to make as a programmer, and this also raises my cognitive load. "What's the best here? Is it sufficiently obvious now? Will it be in the future?"

In short, yes, I would like some prescription. Lessons from the past and all.

    def switch(match, dictionary, default="no match"):
        for key in dictionary.keys():
            if match in key:
                switch.last_match = key
                return dictionary.get(key)
        return default

Using “in” rather than “==“ here seems odd to me, is that intentional?

i.e I’d expect switch(‘abc’, {‘a’: 1}, default=“default”) to return “default”, but under this code it’d return 1, no?

You got that containment backwards;

  switch('a', {'abc': 1}, 'default') #returns 1

... but you're not wrong, that's godawful. But from the context of the article, they're optimizing for the case where multiple cases evaluate to the same answer. It would make more sense to write

  switch('a', {('a','b','c'): 1}, 'default') #returns 1

I'd optimize for performance, personally:

  def switch(match, dictionary, default="no match"):
    return dictionary.get(match, default)

It's not even thread safe.

We’ll have full-bore match in 3.10, what’s the hubbub?

Every article talking about how Python doesn't have, need, or want a switch statement is now redundant.

match doesn't have fallthrough, so I imagine some C-style switch partisans won't be satisfied.

Weiting a module to provide a decorator that can leverage the ast module and rewrite the match block to provide C-style fall-through is left as an exercise for the reader.

C# has some really fancy stuff as of 8.0. See:

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

and

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

I never understood the need for a switch, but one way to do it in python that is not mentioned in the article is to put different functions as the values of your dict. Then do my_dict[my_var]()

Indeed if you use a default dict, you could also emulate imtge pattern more completely.

Happy for it not to have fall-through.

I guess my_dict.get(myvar, default)() would be simple enough.

That said, I never really had a problem not having switch either.

What would make you want it to explicitly not have fall-through? I can't see any negative to including it. If it's something you disagree with can't you just opt to not use?

It's very useful in times for us who use switch regularly. I have no skin in the python game though so just curious from an outside dev haha

Well to be fair, I do use fallthrough in so far as I group cases that are the exact same, but fall-through with slightly different logic is very bug prone and difficult to spot when it is deliberate or an accident, so I basically never use it.

Perhaps some languages conventions are different, but for example Douglas Crockford on JS:

> "switch Statement

A switch statement should be avoided, but when used should have this form:

   switch (expression) {
   case expression:
       statements
   default:
       statements
   }

Each case is aligned with the switch. This avoids over-indentation. A case label is not a statement, and should not be indented like one.

Each group of statements (except the default) should end with break, return, or throw. Do not fall through."

That convention seems a little weird, but what works for different people. Normally case/break seem to light up in ides to help visually double check it has a break. Also not every language that supports fall through, supports having content inside the fall throughs. (C# I just learned recently, does not allow any code in a case that is falling through).

My problem with languages trying to too strictly control stuff like this, is that this is stuff that should be handled in your code review process. Sometimes when working with old code, it's not really worth the time spent refactoring a whole switch when you need to make a small fix, vs adding a single line.

Yep, this pattern is known as Table-Driven Methods.

There's a pattern I have developed for my python scripts of writing a object like that :

    # where a and b are functions
    FOO = { a.__name__: a, b.__name__: b }

and with argparse do

    parser = argparse.ArgumentParser()
    parser.add_argument(
        "-f",
        "--foo",
        choices=FOO.keys(),
        default=next(iter(FOO)),
        help="choose your type of foo",
    )

I quite like that!

> In bash everything is very simple and clear.

doubt

When I read that I was also fairly skeptical... or perhaps it’s my BASH script reading and writing skills which are sub-par (which they most definitely are, but in most other programming languages I can at least appreciate the craft of a master coder when I come across it... but I’ve never ever seen any such wonderful source of amazement in BASH).

fi you can't understand esac there's not much hope done you

Depends what you mean by “understanding ESAC”. Of course I understand CASE/ESAC. I ‘understand’ Duff’s Device in C (even though I don’t think I could’ve ever come up with it myself). I’m just saying that this strikes me as rather... inelegant?

Reply on news.ycombinator.com