A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-June/066602.html below:

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

[Python-Dev] PEP 3103: A Switch/Case StatementFredrik Lundh fredrik at pythonware.com
Tue Jun 27 07:28:31 CEST 2006
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).

</F>

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4