[Python-Dev] First Draft: PEP "Switching on Multiple Values"

[M.-A. Lemburg]

Skip Montanaro wrote:
> 
> Just a few odd comments...

Thanks; I've added them to the next PEP revision.
 
>...
>
>     mal>          To prevent post-modifications of the jump-table dictionary
>     mal>          (which could be used to reach protected code), the jump-table
>     mal>          will have to be a read-only type (e.g. a read-only
>     mal>          dictionary).
> There was discussion once upon a time about adding a read-write flag to
> dictionaries to prevent modification during sensitive times.  I gather lists
> already have such a flag to allow in-place sorting to work.

With the new subtyping mechanism I believe this should be easy
enough to implement as subtype. Could be useful in other cases too.
 
>     ...
>
>     mal>          The compiler could then setup a read-only (perfect) hash
>     mal>          table, store it in the constants and add an opcode SWITCH
>     mal>          which triggers the following run-time behaviour:
> I think it would be sufficient to use a read-only dictionary.  Perfect has
> tables are fine, but who wants to implement one?

You're probably right; the compiler could check for perfectness
though (e.g. the read-only dict could have a method or attribute
for testing this). If its not a perfect hash, there are several
possibilities of arranging for a perfect hash, e.g. double hashing,
slightly increasing the table size etc. I don't think its really
necessary to be picky about the perfectness unless non-perfect
hash tables are common for the current combination of Python 
hash functions and dictionary implementation.
 
>     mal>          At runtime, SWITCH would check x for being one of the
>     mal>          well-known immutable types (strings, unicode, numbers) and
>     mal>          use the hash table for finding the right opcode snippet.
> And if one of the constraints isn't met, it would simply jump to the
> original if/elif/else code?

Right.
 
>     ...
> 
>     mal>     Issues:
> 
>     mal>         There have been other proposals for the syntax which reuse
>     mal>         existing keywords and avoid adding two new ones ("switch" and
>     mal>         "case").
> 
> Here's a wacky idea (probably wouldn't work syntactically, but hey, you
> never know):
> 
>     if EXPR:
>         == CONSTANT:
>             suite
>         == CONSTANT:
>             suite
>         == CONSTANT:
>             suite
>         else:
>             suite
> 
> No new keywords, but I suspect the compiler would have to look too far ahead
> to realise that it's not compiling a regular if statement.

Naa... too weird looking :-)
 
> BTW, do you mean for your "suite"s to be optional?  

No. We decided against fall-through ideas... I'll change them
to SUITE.

> Here are some
> concrete examples using each syntax variant
> ...

Thanks; I've added them to the PEP.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/