syntax difference

bart4858 at gmail.com bart4858 at gmail.com
Thu Jun 21 16:14:14 EDT 2018


Alister:
======
which can be implemented in python by putting function calls as members 
of a list or dictionary 

switch=[case1,case2,case3] 
switch[a]() 
======
This is the approach you might use when you don't have a proper switch. It could be done in C that way.

Problems: the code for the different cases is not localised. You have to think up function names. The cases must be listed in that order. If the first case is not zero, you have to deal with that. Gaps in the sequence are problematical. You need a way of detecting the default case. There is no association between case number and its entry. The case numbers may be named values, so won't know what order they need to be in.

Using a dict will solve some of that, but its not clear what overheads there are in setting up the dict.

A proper switch also allows lists, ranges and scalars, or any mix, for each case block. It's not clear how a dict can be used for that, without adding another layer of processing which defeats part of the purpose in having switch.

Above all, you lose the clarity of a proper switch construct.

Alister:
======
(although i personally would still like to see a switch if anyone can 
come up with a suitable syntax that does not break the rest of the python 
philosophy wtr indentation.) 
======

The syntax is a minor detail. The biggest problem with adding an int-based switch to Python that uses a jump-table is that that requires the case values to be known at compile-time. Usually they won't be.

I came up with a way around this which used tentative byte code which is fixed up the first time it is executed. But that is rather hairy, and it means case values are fixed: if A is a case value of 10, then if later on it is 20, it will be treated as 10 still.

For such reasons it is unlikely to make it into Python in that form.

However a switch statement can still be useful for its expressiveness, and implemented as sequential tests.

-- 
Bart



More information about the Python-list mailing list