M.-A. Lemburg wrote:
Having a simple switch statement would enable writing very fast parsers in Python - ... Instead of having one function call per token, you'd only have a single dict lookup.
BTW, has anyone in this thread actually read the PEP 275 ?
I haven't actually seen any use cases outside of parsers branching on a constant token. When I see stacked elif clauses, the condition almost always includes some computation (perhaps only ".startswith" or "in" or a regex match), and there are often cases which look at a second variable. If speed for a limited number of cases is the only advantage, then I would say it belongs in (at most) the implementation, rather than the language spec. -jJ
On Mon, 2005-04-25 at 18:20 -0400, Jim Jewett wrote: [...]
If speed for a limited number of cases is the only advantage, then I would say it belongs in (at most) the implementation, rather than the language spec.
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
benefits belong in implementation optimisations, not new bad syntax.
--
Donovan Baarda
Donovan Baarda wrote:
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed benefits belong in implementation optimisations, not new bad syntax.
I posted this 'switch' recipe to the Cookbook this morning, it saves some typing over the if/elif/else construction, and people seemed to like it. Take a look: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410692 -- Brian Beck Adventurer of the First Order
On Mon, 2005-04-25 at 21:21 -0400, Brian Beck wrote:
Donovan Baarda wrote:
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed benefits belong in implementation optimisations, not new bad syntax.
I posted this 'switch' recipe to the Cookbook this morning, it saves some typing over the if/elif/else construction, and people seemed to like it. Take a look: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410692
Very clever... you have shown that current python syntax is capable of
almost exactly replicating a C case statement.
My only problem is C case statements are ugly. A simple if/elif/else is
much more understandable to me.
The main benefit in C of case statements is the compiler can optimise
them. This copy of a C case statement will be slower than an
if/elif/else, and just as ugly :-)
--
Donovan Baarda
Donovan Baarda wrote:
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed benefits belong in implementation optimisations, not new bad syntax.
Two things are mildly annoying about if-elif chains as a substitute for a switch statement: 1) Repeating the name of the thing being switched on all the time, and the operator being used for comparison. 2) The first case is syntactically different from subsequent ones, even though semantically all the cases are equivalent. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+
"Greg" == Greg Ewing
writes:
Greg> Two things are mildly annoying about if-elif chains as a Greg> substitute for a switch statement: Greg> 1) Repeating the name of the thing being switched on all the Greg> time, and the operator being used for comparison. What's worse, to my mind, is the not infrequent case where the thing being switched on or the operator changes. Sure, that's bad style, but sometimes you have to read other people's code like that. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
Greg> 1) Repeating the name of the thing being switched on all the Greg> time, and the operator being used for comparison.
What's worse, to my mind, is the not infrequent case where the thing being switched on or the operator changes. Sure, that's bad style, but sometimes you have to read other people's code like that.
You mean like this? if x > 0: ...normal case... elif y > 0: ....abnormal case... else: ...edge case... You have guts to call that bad style! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido" == Guido van Rossum
writes:
Guido> You mean like this? if x > 0: ...normal case... elif y > 0: ....abnormal case... else: ...edge case... The salient example! If it's no accident that those conditions are mutually exclusive and exhaustive, doesn't that code require at least a comment saying so, and maybe even an assertion to that effect? Where you can use a switch, it gives both, and throws in economy in both source and object code as a bonus. Not a compelling argument---your example shows switches are not universally applicable---but it's a pretty good deal. Guido> You have guts to call that bad style! :-) Exaggeration in defense of elegance is no vice.<wink> -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On 4/28/05, Stephen J. Turnbull
"Guido" == Guido van Rossum
writes: Guido> You mean like this?
if x > 0: ...normal case... elif y > 0: ....abnormal case... else: ...edge case...
The salient example! If it's no accident that those conditions are mutually exclusive and exhaustive, doesn't that code require at least a comment saying so, and maybe even an assertion to that effect?
I usually do: if ...: return ... if ...: return ... assert ... return ... Michael
Exaggeration in defense of elegance is no vice.<wink>
Maybe not, but it still sounds like BS to me. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (7)
-
Brian Beck
-
Donovan Baarda
-
Greg Ewing
-
Guido van Rossum
-
Jim Jewett
-
Michael Walter
-
Stephen J. Turnbull