FW: Switch statements again

John Roth johnroth at ameritech.net
Fri Jan 17 21:41:02 EST 2003


"Bengt Richter" <bokr at oz.net> wrote in message
news:b07utn$bd1$0 at 216.39.172.122...
> 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 216.39.172.122...
> >> 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
gains
> >> >> something
> >> >> like a switch statement you can bet the farm it won't have a
"fall
> >thru=
> >> >"
> >> >> feature though, so the way you've coded your C switch statement
> >wouldn'=
> >> >t
> >> >> work.
> >> >>=20
> >> >
> >> >but the absolute /only/ reason you'd use a switch over an if
(besides
> >> >looking better) is fall through.
> >> >
> >> Well, if you look at the code for an optimized C switch I think
you'll
> >> find another reason. I.e., if you can predetermine that all the
switch
> >> case _constants_ form a compact sequence of values, you can
generate a
> >> 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
> >conditional
> >> jumps for boundary cases you may still gain.
> >
> >If all of the switch case _constants_ are single constants, you can
use
> >a dictionary or a list of functions.
> >
> The trouble with (current style) functions is that you can't put code
in them
> to rebind names in the caller's scope (i.e., the scope where you'd be
in an
> 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
those lines
> 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.

>
> Regards,
> Bengt Richter

John Roth






More information about the Python-list mailing list