Dan,
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
else:
functionB(var)
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:
try:
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 On
Behalf Of Dan Sommers
Sent: Sunday, February 3, 2019 8:29 PM
To: python-list@python.org
Subject: Re: Switch function
On 2/3/19 5:40 PM, Avi Gross wrote:
> Bottom line, does anyone bother u
