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/)
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