Another stab at a "switch/case" construct (new proposal):

[Ken Peek]

[Steve Holden]:
"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..."?

[Ken Peek]:
No-- that was not my intent at all.  Dynamic objects could be used as
well, with the compiler optimizing the 'literal only' cases.

[Steve Holden]:
"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)."

[Ken Peek]:
As to the considerable resistance-- I think that is a good thing, but
no reason to never discuss language enhancements.  Who knows?  Maybe
some day, someone will come up with a really good enhancement to
Python that has a huge upside, and very little downside.  You note
about the 'match' keyword is well taken.

[Dale Strickland-Clark]:
"You *have* to allow variables in the match list, however, plus
objects that evaluate to a suitable value or sequence of values.
There's no reason why the compiler couldn't detect and optimize the
case where only constants are used." ... "I prefer 'else' to 'any' - a
lot. I makes more sense and doesn't need a new keyword."

[Jeff Shannon]:
"I think that if we're going to add a keyword for this, that "switch"
is a good choice.  It's familiar to C/C++ programmers (at least), it's
reasonably intuitive, and it avoids capitalization monstrosities. ;) 
It does risk breaking old code, of course, but then, *any* keyword
change does that."  "I do prefer the re-use of "else" instead of
adding "any", though. A lot."  "I don't think I like this re-use of
the 'continue' keyword -- it seems to me that the sense, in this
context, is considerably different than the sense of its use in a
loop.  In a loop, it means 'start over from the top', where here, it
means 'run this one next bit too, but not anything else'."  "I'm not
sure that falling through is a necessary idiom to accommodate...."

[Ken Peek]:
Yes-- a keyword to fall through a matched case body to the next is
ESSENTIAL to efficiency and readability.  Also, this fall through
capability is one of the most powerful aspects of the switch/case
construct.

[damien morton]:
"You could go a lot further with this case statement.  First thing is
to allow for variable length list unpack..."

[Ken Peek]:
Interesting idea.  I don't think I'm smart enough to use that level of
complexity though...

[Bengt Richter]:
"case:  Don't like it.  We already have means to do what a case does
and do it more elegantly.  It would add a needless redundant portion
to the language."

[Ken Peek]:
Thanks for your opinion!  Well, I think the most important thing about
Python is that it encourages a programmer to write code that is both
readable and maintainable.  I think I said in my post that you COULD
do the same thing with if/elif/else clauses, but that this construct
is more readable.  Python is not about minimizing the number of
keywords or keystrokes-- it is about READABILITY and MAINTAINABILITY. 
I think a switch/case type of construct would go a long way towards
this goal.

[Laura Creighton]:
"I don't like the overloading of continue.  I'd go for a new keyword,
fallsthrough myself."

[Ken Peek]
(see new proposal below)

==================================
[switch/case keyword selection]:

Many people have expressed that they don't like the use of the keyword
'match', and others have also taken issue of my overloading the of the
keyword 'continue', so I have thought of some alternatives:

['match']:
search, find, seek, branch, branchon, switch, switchon, pick, choose,
select, multibranch

['continue']:
fall, fallthrough, sink, descend, proceed

After hearing the comments of the folks on this news group, I now
think that the use of tuples in this construct was a big mistake-- I
should have proposed the use of lists instead.  Below is a "new
improved version" of the 'switch/case construct, along with my
preference for the new keywords:

##### Another Example #####

from __future__ import multibranching

MyObject = Something

# The "==" test will be used to determine if a match occurred.
# The type, size, number of elements, keys (if any) and values
# of the object being compared must all match exactly for a
# clause to be declared as equal. The lists of the clauses are
# examined recursively. If "MyObject" is itself a list, then
# the first matching list terminates the recursive examination
# of the values in the clauses. The values in the clauses are
# examined exactly in the order as written (top to bottom,
# left to right), and the first matching value terminates the
# examination, causing the matching clauses body to be
# executed. If the last statement in a clause body is a
# "fallthrough", then the body of statements in the following
# clause are also executed:

branchon MyObject:

    [Object_1, Object_N, (99,98,MyVar), 42]:
        # do something
        # do more
        fallthrough # (fall through to next clause body)
    [[1,2,3], "hello", MyDynamicObject, MyList]:
        # do something
        # do more

    []:
        # this matches if "MyObject" is an empty list
        # do something
        # do more

    else:
        # we did not have any matching clauses
        # do something
        # do more

==================================

OK-- please send in the next barrage of critisism...