Phillip J. Eby wrote:
Hear, hear! We already have if/elif, we don't need another way to spell
it. The whole point of switch is that it asserts that exactly *one* case
is supposed to match
that's not true for all programming languages that has a switch construct,
though;
the common trait is
On 6/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
Hear, hear! We already have if/elif, we don't need another way to spell
it. The whole point of switch is that it asserts that exactly *one* case
is supposed to match
that's not true for all programming languages
Guido van Rossum wrote:
that's not true for all programming languages that has a switch construct,
though;
the common trait is that you're dispatching on a single value, not
necessarily that
there cannot be potentially overlapping case conditions.
You have a point.
that can happen to
On 6/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
I just wish I could figure out what school my original micro-PEP belongs
to (but as long as my implementation note is still just a draft, I guess no-
body else can figure that out either... ;-)
There aren't just schools; there are alternatives
On compilation, freeze any cases that meet the School-II conditions
and have a trustworthy __hash__ method into a dictionary.
As long as the semantics are based on if-elif, you have to support
if(optimizable)
elif (has a side effect)
elif (optimizable)
elif (not
Here's a possible adjustment to the School-II approach that i think
avoids the issues i've been raising, while giving the desired
O(n)-to-O(1) speedup in common situations. It's basically School-II
dispatch, plus a check:
On compilation, freeze any cases that meet the School-II conditions
and
