[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Switch function


I agree and have felt no need to do a method like this. Most of the time a
switch is easy to avoid or even forget that it exists.  I rarely needed to
use these years ago when they were available in C and C++ , JAVA,
JavaScript, PERL  or R or under  other *names* but similar functionality
like COND in versions of LISP or CASE in PASCAL.

The times I would use it would not be when were a relatively few cases. It
makes more sense for example when you are accepting a one-character command
in the very old style from the user. I repeat, OLD style. Your main loop may
largely consist of a switch statement where every possible keystroke calls
one of a set of functions. I mean things like D is for Delete and I is for
insert and A is for Append and Q is for QUIT and some are absolutely not
mnemonic like V is for Paste.

I have read books that suggest having a long function is a sign of clutter
or even insanity and I feel that is not realistic in many cases. 

The example I show above could in many cases be done as you describe but
what are you gaining?

I mean if I subtract the integer representation of a keyboard alphabetic
letter (ASCII for the example) from letter 'a' or 'A' then A maps to 0 and B
maps to 1 and ...  Z maps to 26. So, you could make a list of 26 functions
(some may be absent) and your entire switch statement looks like:

	funcs=[zeroeth,first,other,...,last] # list of function handles
	var=input("Enter a Command: ")
	if ord('A') <= ord(var[0]) <= ord('Z'):
		result = funcs[ord(var[0]) - ord('A')]()

Is that short enough?

Mind you, that is not the same as a switch statement form that allows
arbitrary code after each choice and lets you access variables at that level
and change them, as well as call functions with specific arguments that make
sense at that time. Yes, judicious use of the global or nonlocal statement
can dangerously get you some of that functionality.

A reasonable goal might be to have the code at each case be relatively
brief. Maybe a few lines adjusting local variables then calling a function
that lets more code be elsewhere by passing in additional things needed in
that context or passing in mutable arguments. The indentation should make it
reasonable to follow as if you are looking at N different functions where
each one is not too large even if it is all in one large switch.

Now this sounds quite a bit like the dictionary trick but note many of the
above languages do not have a built-in dictionary concept and some may not
support lists of functions or objects. I have seen monstrosities like this:

functionTop is:
	If var == 'A':
		# do something

Guess what functionB says?

Yep, if it is 'B" do something else call functionC.

So a mere 26 functions, each short and stacked. Ugh!

It may be a matter of taste and I have seen places such as statistical
calculations where such an approach is even needed. In very brief, some
tests require a choice of TWO so one choice is A versus non-A and then you
do something with the non-A that are B versus non-B.

Your comment about object polymorphism is interesting. I am picturing how
each choice somehow delivers an object that automatically is set up to do
the right thing.

Having said that, I realize how there is something in python quite similar
to a case statement!

Picture my example where you have a try statement that raises at least 26
error objects followed by up to 26 catch statements:

		something that raises a designer exception
	catch errorA as var: pass
	catch errorb, errorB: pass
	catch errorZ: pass

That looks like a switch in many ways and lets you combine multiple choices
into one case. Heck, there is also a finally and else clause you can use for
fine tuning as in setting a default.

Again, see how can you write a COMPLICATED try command that captures many
things including real errors?

I know I keep repeating this but experience tells me that if not mentioned,
someone will make believe I meant something other than what I say. The above
is NOT a suggestion of what to do. It is an example of another feature that
IS in the language that in some ways is much like the switch statement. Not
always a good idea to abuse it when it can be done with IF variants or a
dict jump or many other gimmicks.

In the above the  *raise* statement within whatever you try can do the same
trick as before and create a small integer offset from letter 'A' to use in
making a slightly different object for each case in one of many ways. I will
stop here.

-----Original Message-----
From: Python-list < at> On
Behalf Of Dan Sommers
Sent: Sunday, February 3, 2019 8:29 PM
To: python-list at
Subject: Re: Switch function

On 2/3/19 5:40 PM, Avi Gross wrote:

> Bottom line, does anyone bother using anything like this? It is 
> actually a bunch of hidden IF statements matched in order but may meet
many needs.

I sure don't.  In the rare case that I might use a switch statement in
another language, I just use a series of elifs, or maybe a dictionary I
build once and use over and over (a habit left over from the old days of
extremely constrained systems, when medium-to-large lookup tables and simple
logic was better than many kinds of runtime computation).

If it gets unweidly, I think harder about how to isolate the "switching"
from the results, and usually end up with a collection of smaller functions
to do the work, or high order functions, or maybe some sort of object
oriented polymorphism as a last resort.