471,313 Members | 1,932 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,313 software developers and data experts.

Using a switch-like if/else construct versus a dictionary?

Which is better: using an if/else construct to simulate a C switch or
use a dictionary? Example:

def foo():
if c == 1:
doCase1()
elif c == 2:
doCase2()
elif c == 3:
doCase3()
elif c == 4:
doCase4()
elif c == 5:
doCase5()
else:
raise "shouldn't get here"
or:

def foo():
def doCase1():
pass
def doCase2():
pass
def doCase3():
pass
def doCase4():
pass
def doCase5():
pass

handle_case = {}
handle_case[1] = doCase1()
handle_case[2] = doCase2()
handle_case[3] = doCase3()
handle_case[4] = doCase4()
handle_case[5] = doCase5()
handle_case[c]()

Note that in this situation using OO polymorphism instead of a switch-
like construct wouldn't be applicable, or at least I can't see how it
could be.

Thanks in advance for any tips!

-- Arcadio

Jun 19 '07 #1
6 1593

asincero ha escrit:
def foo():
def doCase1():
pass
def doCase2():
pass
def doCase3():
pass
def doCase4():
pass
def doCase5():
pass

handle_case = {}
handle_case[1] = doCase1()
handle_case[2] = doCase2()
handle_case[3] = doCase3()
handle_case[4] = doCase4()
handle_case[5] = doCase5()
Sorry, but I think this is not correct. Now, you put the result of the
function call into the dictionary, but you want the function address.

The correct code is:
handle_case = {}
handle_case[1] = doCase1
handle_case[2] = doCase2
handle_case[3] = doCase3
handle_case[4] = doCase4
handle_case[5] = doCase5

Or:
handle_case = { 1: doCase1, 2: doCase2, 3: doCase3, 4: doCase4, 5:
doCase 5 }

Or:
try:
{ 1: doCase1, 2: doCase2, 3: doCase3, 4: doCase4, 5: doCase 5 }
[c]()
except:
print "Catch the correct exception"

But this solutions only works fine if the params of the functions are
the same for all calls (in if/else construct you don't need it).

Bye!

--
Helio Tejedor

Jun 19 '07 #2
asincero <as******@gmail.comwrote:
Which is better: using an if/else construct to simulate a C switch or
use a dictionary? Example:
Here is a technique I've used a lot. I think I learnt it from "Dive
into Python"

class foo(object):
def do_1(self):
print "I'm 1"
def do_2(self):
print "I'm 2"
def do_3(self):
print "I'm 3"
def do_4(self):
print "I'm 4"
def do_5(self):
print "I'm 5"
def dispatch(self, x):
getattr(self, "do_"+str(x))()

f = foo()
f.dispatch(1)
f.dispatch(3)
f.dispatch(17)

It will blow up gracelessly with an AttributeError if you pass it
something which it can't handle. That is easy to fix.

You could name dispatch, __call__ if you wanted a slightly neater
syntax.

f = foo()
f(1)
f(3)
f(17)

You can do the same thing in a function using locals()["do_"+str(x)]
but I always find that if I've got to that point I should be using a
class instead.
Note that in this situation using OO polymorphism instead of a switch-
like construct wouldn't be applicable, or at least I can't see how it
could be.
If there is a "type" or "id" in your objects and you are switching on
it, then you should be using polymorphism. Make each seperate "type"
a seperate class type and implement the methods for each one. All the
switches will disappear from your code like magic!

Post more details if you want more help!

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Jun 19 '07 #3
asincero <as******@gmail.comwrites:
def foo():
def doCase1():
pass
def doCase2():
pass
def doCase3():
pass
def doCase4():
pass
def doCase5():
pass

handle_case = {}
handle_case[1] = doCase1()
handle_case[2] = doCase2()
handle_case[3] = doCase3()
handle_case[4] = doCase4()
handle_case[5] = doCase5()
handle_case[c]()
(The above code is wrong. You want the dictionary to map to functions,
not to the result of calling those functions; the call to the function
comes later.)

Why not construct the dictionary in one step? ::

handle_case = {
1: do_case_1,
2: do_case_2,
3: do_case_3,
4: do_case_4,
5: do_case_5,
}
handle_case[c]()

You could even perform the lookup and function call in the same
statement as creating the dictionary, but I prefer the above form for
its readability.
Note that in this situation using OO polymorphism instead of a switch-
like construct wouldn't be applicable, or at least I can't see how it
could be.
I'm not sure what you mean. What would you apply polymorphism to, and
what would be the desired result?

--
\ "I used to work in a fire hydrant factory. You couldn't park |
`\ anywhere near the place." -- Steven Wright |
_o__) |
Ben Finney
Jun 20 '07 #4
asincero <as******@gmail.comwrote:
handle_case = {}
handle_case[1] = doCase1()
handle_case[2] = doCase2()
handle_case[3] = doCase3()
handle_case[4] = doCase4()
handle_case[5] = doCase5()
handle_case[c]()
If the switch values are simple integers then a list would be a more
obvious choice:

handle_case = [ doCase1, doCase2, doCase3, doCase4, doCase5 ]
handle_case[c-1]()
Note that in this situation using OO polymorphism instead of a switch-
like construct wouldn't be applicable, or at least I can't see how it
could be.
That is often the case when you reduce your question to a mickeymouse do
nothing example.

There are many ways to write code that could be written using a switch
statement. If you took a few real use-cases then you would probably each
one needs a different technique for best effect depending on the number
of different cases, the values which must be accessed within each case,
the side-effects (if any) expected from handling the case etc.

The obvious options include: if/elif chain; a list or dictionary
containing data values (not functions); a list or dict containing
functions; command pattern (i.e. a class with a dispatch method); a
class hierarchy and polymorphism; visitor pattern.

For an example of the last of these see
http://www.chris-lamb.co.uk/blog/200...ern-in-python/
which uses decorators to produce a very clean implementation using (I
think) PyProtocols dispatch.
Jun 20 '07 #5
Ahh .. yes of course, you are right. I mis-typed. I like how you
defined the dictionary all in one statement, though. I didn't think
of doing it that way.

-- Arcadio
On Jun 19, 4:11 pm, heltena <helt...@gmail.comwrote:
asincero ha escrit:
def foo():
def doCase1():
pass
def doCase2():
pass
def doCase3():
pass
def doCase4():
pass
def doCase5():
pass
handle_case = {}
handle_case[1] = doCase1()
handle_case[2] = doCase2()
handle_case[3] = doCase3()
handle_case[4] = doCase4()
handle_case[5] = doCase5()

Sorry, but I think this is not correct. Now, you put the result of the
function call into the dictionary, but you want the function address.

The correct code is:
handle_case = {}
handle_case[1] = doCase1
handle_case[2] = doCase2
handle_case[3] = doCase3
handle_case[4] = doCase4
handle_case[5] = doCase5

Or:
handle_case = { 1: doCase1, 2: doCase2, 3: doCase3, 4: doCase4, 5:
doCase 5 }

Or:
try:
{ 1: doCase1, 2: doCase2, 3: doCase3, 4: doCase4, 5: doCase 5 }
[c]()
except:
print "Catch the correct exception"

But this solutions only works fine if the params of the functions are
the same for all calls (in if/else construct you don't need it).

Bye!

--
Helio Tejedor

Jun 20 '07 #6
On Jun 19, 12:40 pm, asincero <asinc...@gmail.comwrote:
Which is better: using an if/else construct to simulate a C switch or
use a dictionary? Example:
Whichever results in the clearest code that meets the performance
requirements.

FWIW, if you define the dictionary beforehand, the dict solution is
O(1) while if/else is O(N), which can be important.

-Mike

Jun 25 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Robert Scheer | last post: by
1 post views Thread by wayneh | last post: by
27 posts views Thread by Yuriy Solodkyy | last post: by
25 posts views Thread by v4vijayakumar | last post: by
10 posts views Thread by kkirtac | last post: by
reply views Thread by srinivas srinivas | last post: by
11 posts views Thread by =?Utf-8?B?anAybXNmdA==?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.