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> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com