On 19 April 2014 05:12, Steven D'Aprano steve-at-pearwood.info | python-ideas-at-python.org| firstname.lastname@example.org wrote:
In the case of your tarot example, it is *not* a violation of DRY, because the various elif lines are not *sources* of knowledge which may contradict each other. The worst that will happen is that if you change the variable name "tarot" to something else, your code will fail with a name error.
You could also use another existing variable. Anyway
motive in introducing a switch/case statement is to DRY, I think you
need a better motive.
I completely agree. I think the main good reason to introduce a switch statement is that is more simple to use, when it can be used.
@Skip Montanaro: yes, switch statement is used in C also for code
optimization. Frankly, I think this aspect is unimportant for CPython in the present time.
Then I think we're not going to agree on the use or need for switch.
To be clear: I'm not saying you can't improve the performance of a switch statement, but IMHO currently Python has worse speed problems.
On 19 April 2014 07:11, Stephen J. Turnbull stephen-at-xemacs.org | python-ideas-at-python.org| email@example.com wrote:
Skip Montanaro writes:
In other languages, the semantics of the switch statement allow the compiler to generate more efficient code. Instead of testing each branch of the if statement in succession looking for a match, you evaluate the switch expression once, then use it as an index into a jump table of some sort which points directly to the matching case label.
Sure, but Python already has such a jump table: a function-valued hash.
Yes, I think it's more befitting than a switch.
On 19 April 2014 08:52, Bruce Leban bruce-at-leapyear.org | python-ideas-at-python.org| firstname.lastname@example.org wrote:
Here's a simple class that provides case like syntax. How would modifying the language be better than this?
I don't like the additional unneeded Case indentation. That's why I'm proposing a syntax with switch on the same line with the first case.
I think case/elcase would be confusing as it would be unique to python and
it's backwards -- the elcase keywords is used for the normal way that people use case statements while the case keyword implements the broken code that inexperienced C programmers frequently write.
This is the point. When I was a beginner I have not tried to code Python directly, since it was an "exotic" language for me; so I read tutorials and docs. In tutorial there will be an example with elcase, and if I have C background I'll think "what damn is elcase"? And I'll read docs more carefully. And what if I read the code? If I don't know how switch statement works in Python and I read a Python code with elcase, the result will be the same. If I read an example without elcase, since it will work as a C switch statement, there's no possibility of misunderstanding.
The problem with C switch is that you have to write break; at the end of each case suite, and typically you forget to do it. With my proposal you can't forget it if you know the syntax.