[Python-Dev] PEP 3103: A Switch/Case Statement

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