On 2/3/19 9:03 PM, Avi Gross wrote:
> 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?
It's not a matter of shortness. Your code encapsulates the idea of
dispatching to a 0-airity function based on an input. In Python,
though, I'd still use a dictionary, which would be more flexible (what
if I start to use digits or other characters as commands?) and less
error prone.
> 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.
Disclaimer: I speak OO as a second language, and only when there is an
obvious and compelling advantage over some other paradigm. That said:
If the mapping from input to function is more complex than A -> func1, B
-> func2, etc., then a factory function that builds an object with an
execute method is a good way of isolating the mapping and keeping the
main code clean and clear.
> Again, see how can you write a COMPLICATED try command that captures
> many things including real errors?
Don't do that. Why are you writing COMPLICATED try commands?
Did you have a Python question? ;-)
--
https://mail.python.org/mailman/listinfo/python-list
