case/switch statement?

[Peter Hansen]

Since you and Steve Holden agree that a case statement is useful, why
don't you propose it for python, or add it to the wiki page for Python
3000.

Two simple reasons.

1. You forgot my previous comment that "in current Python the equivalent
approach is, of course, a dictionary of some kind, though it's arguable
whether this is as clean in many cases as a case statement would be."

2. Just because something is "useful" doesn't mean it should be added to
Python. The bar should be set much higher, and should include at least
"and significantly better than any existing alternative way of doing the
same thing." Now go read point 1 again... ;-)

My point was not to suggest that I want a case statement in Python, nor
even that a case statement is a good thing to have in a language (though
it might be... it's not my place to say). My point was simply to point
out that performance is not the only reason to use a case statement.

-Peter

 

[D H]

Two simple reasons.

1. You forgot my previous comment that "in current Python the equivalent
approach is, of course, a dictionary of some kind, though it's arguable
whether this is as clean in many cases as a case statement would be."

I didn't forget that. I never read it, and I don't see the relevance to
my suggestion. Now that I've read it, I would hardly call using a
dictionary as a switch statement, the "equivalent". The fact that
people use a dictionary as a conditional is a python wart.

2. Just because something is "useful" doesn't mean it should be added to
Python. The bar should be set much higher, and should include at least
"and significantly better than any existing alternative way of doing the
same thing." Now go read point 1 again... ;-)

Now go read my message again. I made a suggestion to you. I didn't say
that a switch statement should be added myself. I would never propose
that because the chances of it being added are microscopic.

My point was not to suggest that I want a case statement in Python, nor

Neither was the MY point, which you seem to have inferred.

even that a case statement is a good thing to have in a language (though
it might be... it's not my place to say). My point was simply to point
out that performance is not the only reason to use a case statement.

I don't think you could have misread my simple suggestion to you any
more completely than you did.

 

[Peter Hansen]

Peter Hansen wrote:

[some stuff Doug didn't like]

I don't think you could have misread my simple suggestion to you any
more completely than you did.

Sorry, I'll try harder next time.

-Peter

 

[D H]

Peter Hansen wrote:

[some stuff Doug didn't like]

Actually, this is what you snipped, stuff you didn't like, because the
very mention of "boo" causes you such fits:

 

[Andrew Durdin]

I would hardly call using a
dictionary as a switch statement, the "equivalent". The fact that
people use a dictionary as a conditional is a python wart.

Not at all. A case statement is nothing more than a literal mapping of
constant values to the execution of code blocks; a dictionary is a
(not necessarily literal) mapping of hashable (not just constant)
values to other values. A dictionary is a very close match for the
operation of a case statement.

In the common (in my experience) instance where the case statement is
like (using C notation):

switch(x) {
case 1: y = foo; break;
case 2: y = bar; break;
case 3: y = baz; break;
default: y = qux;
}

In this case the dictionary is obviously a better and clearer choice.
I've generally found for other circumstances where I've used switch
statements that the code ends up more readable if it's reorganised so
that the switch statements are all of the form above, or are
eliminated entirely--so I don't miss a switch/case statement in
Python.

And, just because we can, the most direct equivalent (in terms of
written code) of a switch/case statement in Python is:

exec {
1: "y = foo",
2: "y = bar",
3: "y = baz"
}.get(x,"y = qux")

But I didn't say it was nice...

 

[Martin Miller]

Terry> Yeah, and I find this even more so:

Terry> case = {
Terry> 5: do_this,
Terry> 6: do_that,
Terry> }
Terry> case.get(x, do_default)()

Terry> Which is looking pretty close to a case statement, anyway.

Sure, modulo namespace issues.

Skip

The namespace issue alluded to doesn't exist when using the very
similar approach suggested earlier in this thread by Andrew Durdin --
shown again below in a [very] contrived example illustrating access to
the local namespace:

greeting = "Hello there, "
x = 2

exec {
1: """greeting += 'Tom'""",
2: """greeting += 'Dick'""",
3: """greeting += 'Harry'""",
}.get(x, """greeting += 'Unknown'""")

print greeting

Martin

 

[Skip Montanaro]

Martin> The namespace issue alluded to doesn't exist when using the very
Martin> similar approach suggested earlier in this thread by Andrew
Martin> Durdin

Sure, but I don't think I want to pay the cost of the exec statement.
if/else would probably be quicker.

-- shown again below in a [very] contrived example
Martin> illustrating access to the local namespace:

Martin> greeting = "Hello there, "
Martin> x = 2

Martin> exec {
Martin> 1: """greeting += 'Tom'""",
Martin> 2: """greeting += 'Dick'""",
Martin> 3: """greeting += 'Harry'""",
Martin> }.get(x, """greeting += 'Unknown'""")

Martin> print greeting

Martin> Martin

Martin> --
Martin> http://mail.python.org/mailman/listinfo/python-list

 

[NickC]

In this case the dictionary is obviously a better and clearer choice.
I've generally found for other circumstances where I've used switch
statements that the code ends up more readable if it's reorganised so
that the switch statements are all of the form above, or are
eliminated entirely--so I don't miss a switch/case statement in
Python.

I find the lack of a switch statement encourages me to write
data-driven programs (which is a god-send when I have to enhance them
later to deal with additional cases).

The thing I love most about Python is the fact that callables can be
slung around at run-time, just like any other object. So, I set up
(usually for command-line options) mappings from options to callables
which define "how to perform action x".

Then as the options are translated, I query the lookup tables, and
store the results in appropriately named variables (e.g
"create_connection", "connect_link" for a program I use to test serial
data circuits with a variety of connections and links running over
different hardware).

The main body of the program is then comparatively trivial, because it
just calls methods whose names describe (in a high-level way) what they
do. A new connection or link type can be handled just by adding an
entry to the appropriate dictionary.

Basically, it's the GoF Strategy pattern, without all the pain that's
required to set it up in static languages.

Cheers,
Nick.

 

[Roy Smith]

The thing I love most about Python is the fact that callables can be
slung around at run-time, just like any other object.

Yup. A while ago, I was doing a lot of file parsing with state machines.
Each state was a function. The main loop of the state machine was just:

state = start
while state != end:
state, output = state (input)

Each function was responsible for returning a (nextState, output) tuple.