Phillip J. Eby wrote:
>> I don't see this as much of a problem, really: we can simply restrict
>> the optimization to well-known data types ("homogenous" switches using
>> integers or strings should cover 99.9% of all practical cases), and then
>> add an opcode that checks uses a separate dispatch object to check if
>> fast dispatch is possible, and place that before an ordinary if/elif
>> sequence.
>
> What about switches on types? Things like XML-RPC and JSON want to be able
> to have a fast switch on an object's type and fall back to slower tests
> only for non-common cases.
good point (and nice example).
> for t in obtype.__mro__:
> switch t:
> case int: ...; break
> case str: ...; break
> else:
> continue
> else:
> # not a recognized type
but I wonder how confusing the "break inside switch terminates the outer
loop" pattern would be to a C programmer...
</F>
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