[Python-Dev] PEP 3103: A Switch/Case Statement (original) (raw)

Guido van Rossum guido at python.org
Tue Jun 27 07:37:33 CEST 2006

On 6/26/06, Fredrik Lundh <fredrik at pythonware.com> wrote:

Guido van Rossum wrote:

> Most school I proponents (perhaps you're the only exception) have > claimed that optimization is desirable, but added that it would be > easy to add hash-based optimization. IMO it's not so easy in the light > of various failure modes of hash(). (A possible solution would be to > only use hashing if the expression's type is one of a small set of > trusted builtins, and not a subclass; we can trust int.hash, > str.hash and a few others.) that's the obvious approach for the optimize-under-the-hood school -- only optimize if you can do that cleanly (to enable optimization, all case values must be either literals or statics, have the same type, and belong to a set of trusted types). this gives a speedup in all main use cases, and clear semantics in all cases. another approach would be to treat switch/case and switch/case-static as slightly different constructs; if all cases are static, put the case values in a dictionary, and do the lookup as usual (propagating any errors).

I think we need a PEP for const/static/only/cached/precomputed or whatever people like to call it.

Once we have (say) static, I think making the case expressions static by default would still cover all useful cases, and would allow us to diagnose duplicate cases reliably (which the if/elif chain semantics don't allow IIUC).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list