FW: Switch statements again
johnroth at ameritech.net
Sat Jan 18 03:41:02 CET 2003
"Bengt Richter" <bokr at oz.net> wrote in message
news:b07utn$bd1$0 at 126.96.36.199...
> On Thu, 16 Jan 2003 11:10:43 -0500, "John Roth"
<johnroth at ameritech.net> wrote:
> >"Bengt Richter" <bokr at oz.net> wrote in message
> >news:b05r5n$oan$0 at 188.8.131.52...
> >> On Wed, 15 Jan 2003 18:21:40 -0500, Steven Scott
> ><bodoni26 at resnet.gatech.edu> wrote:
> >> >Quoting Steven Scott <Steven.Scott at Synchrologic.com>:
> >> >>=20
> >> >> If/elif/else remains the most common method. If Python ever
> >> >> something
> >> >> like a switch statement you can bet the farm it won't have a
> >> >"
> >> >> feature though, so the way you've coded your C switch statement
> >> >t
> >> >> work.
> >> >>=20
> >> >
> >> >but the absolute /only/ reason you'd use a switch over an if
> >> >looking better) is fall through.
> >> >
> >> Well, if you look at the code for an optimized C switch I think
> >> find another reason. I.e., if you can predetermine that all the
> >> case _constants_ form a compact sequence of values, you can
> >> computed jump through a table that is a lot faster than a series of
> >> conditional jumps, and even in cases where you have to introduce
> >> jumps for boundary cases you may still gain.
> >If all of the switch case _constants_ are single constants, you can
> >a dictionary or a list of functions.
> The trouble with (current style) functions is that you can't put code
> to rebind names in the caller's scope (i.e., the scope where you'd be
> if/elif version of the case statement).
> However, if you could define transparent same-scope functions, it
could be different,
> and also avoid most of the call overhead. I posted some musings along
> in a thread some time ago.
That certainly is a problem with just about any approach that abstracts
out a separate function to do something.
After spending a few seconds on thinking about it, I will admit that I
couldn't come up with anything obvious that wasn't as ugly as sin
and that didn't pose problems.
> Bengt Richter
More information about the Python-list