Another stab at a "switch/case" construct (for Python 3000):

[Steve Holden]

[posted & mailed]

"Ken Peek" <Ken.Peek at SpiritSongDesigns.comNOSPAM> wrote in message
news:3ca33c88 at news.mhogaming.com...
> Well-- OK, my new ISP doesn't have a news server, but I found one
> that I could use to post this with.  If you reply to my email, do
> the 'nospam' thing first to my email address...
>
> I really am interested in what people think about this.  I have
> looked at all the other c.l.py posts on this construct, but I
> don't think anyone proposed this format.
>
[ ... ]
>
>   How about:
>
>   match some_object:
>
>       ("I dream of Jeanie",):
>           print "with the light brown hair"
>
>       (1,3,5,7):
>
>           print "some odd numbers"
>
>           # 'break' leaves the entire match structure
>           if (time_to_leave): break
>
>           # 'continue' jumps to the first
>           # statement in the next clause
>           continue
>
>       (123,456,789):
>
>           print "some bigger numbers too"
>
>       (19,56,22):
>
>           print "some random numbers"
>
>       (1001,2002,3000):
>           # YES! It IS possible we want to do NOTHING!
>           pass
>
>       any:
>           print "we got here because there were no matches"
>
>   This is kind of a neat construct because you can put multiple
>   tests on one line, and it doesn't look too messy (like C's
>   'switch' would look.)  Also-- we are not limited to matching up
>   only integers.  This is very clean code compared to a long string
>   of "if/elif/elif/elif/else" clauses...  I like READABLE code--
>   which is why I like Python!
>
>   Note that the aggregate of the tuples must have unique values and
>   types-- (this allows for efficient implementation, and for future
>   optimization.)  A match is found only when BOTH the type and
>   value are the same.  'some_object' can be any object, but it
>   would be wise to not use floating point numbers or other things
>   that do not guarantee a valid '==' compare.  I suppose these
>   ambiguous types could be flagged with an error from the compiler,
>   but I would hate to see a run time check (which would slow things
>   down, just to accommodate a bad programmer.)
>
>   The match clauses do not 'fall through' automatically like a "C -
>   switch" statement-- (this is the source of many errors in 'C'.)
>   A clause can be forced to 'fall through' with the use of a
>   'continue' statement, which jumps to the first statement in the
>   next match clause (because 'falling through' IS useful
>   sometimes.)  I suppose the interpreter/compiler could flag an
>   error "UnreachableCode" (or 'BadIndentation') if 'continue' was
>   used by itself, and there were statements after it at the same
>   indentation level...
>
>   The 'any' keyword could be changed to 'else' I suppose, but I
>   think the word 'any' "just plain sounds better when you say it",
>   and I like the 'match' keyword better than anything I have seen
>   or can think of...
>
[ ... ]
Well I don't know how easy it would be to introduce this from a syntactic
point of view. Others will probably comment on that.

Your example uses only constant (literal) values. This obviously makes it
possible to guarantee that the tuples do not overlap at compile time, but is
very restrictive. Was this intentional, or would your scheme also allow

    match some_object:

        (something_else):
            pass

        (this, that, the_other, 42):
            complex_processing

This would be more flexible, but might make it necessary to accept "firsty
matching value".

You will find there is considerable resistance to adding new keywords, due
to their propensity to break existing code (for example, I have some
programs that use match as a variable name, and the re module uses it as the
name of a method).

regards
 Steve