On 15/03/2016 00:58, Chris Angelico wrote:
On Tue, Mar 15, 2016 at 11:54 AM, BartC <b...@freeuk.com> wrote:
In Python, there's no reason to restrict 'switch'
to integers, so I would expect its semantics to be based on either
equality comparisons or inequality comparisons
I use two forms of switch: one for integers only (very fast), and the other
for any other values, which does tests in sequence.
I'm not sure what you gain by restricting to integers that you
couldn't also gain with other hashable types. Can you elaborate on
these optimizations?
The integer-switch is intended for use with jump-tables, which requires
not only that the case expressions are known at compile-time, but that
they don't span too large a range.
(When a jump-table couldn't be used, then there was a slightly different
implementation which scanned a list of the case-expressions. Linearly; a
binary search or hash look-up could be done too, but this was in fast
static code, not interpreted, so was not too critical. But I don't use
this any more anyway.)
For use with Python, because constant expressions are going to be
limited, such a switch would only work with case expressions that are
numeric literals or character constants, which have to be written
b"A"[0] iirc. So rather limited unless someone introduces named
constants at the same time...
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
