On 2014-02-28, Marko Rauhamaa <ma...@pacujo.net> wrote:
> Chris Angelico <ros...@gmail.com>:
>
>> Can you elaborate on this "nonliteral constants" point? How is it a
>> problem if DISCONNECTING isn't technically a constant? It follows the
>> Python convention of being in all upper-case, so the programmer
>> understands not to rebind it. Is the problem that someone might
>> (naively or maliciously) change the value of DISCONNECTING, or is the
>> problem that Python doesn't fundamentally know that it won't change?
>
> This last point. It would make it impossible for Python to treat the
> switch statement as anything but an alternate form of chained if-else.
There are a couple nice things about a switch () statement:
1) It guarantees that 'expr' is evaluated exactly once. If you want
that with a chained if/else you have to create a temporary variable.
2) It guarantees that exactly one path is chosen (assuming we're not
going to duplicate C's "fall through" mistake).
The result is that it makes the author's intention instantly clear to
the reader: we're going to evaluate some expression _exactly_once_ and
then select _exactly_one_ of several paths based on that value. Sure,
you can do the same thing with a chained if/elif/else, but it requires
some effort for the reader to figure that out. Accidently type "if"
instead of "elif" two thirds of the way down, and you get something
that works right _most_ of the time, but not always. [Not that _I've_
ever done that and then read through the whole thing six times over a
period of two days before noticing it.] :)
<reductio ad absurdum>
If the availability of an alternate but computationally equivalent
representation was a valid argument against a language feature, then
we ought to toss out Python entirely: It's always possible to write
the exact same algorithm, so why bother with Python?
</reductio ad absurdum>
> A dict optimization wouldn't actually optimize anything because it
> would have to be constructed every time the statement is executed.
I don't think question should be "how does this help the compiler?"
The question should be "how does this help the _user_ of the compiler?
The user of the compiler spends more time reading code than anything
else. Something that makes code easier to read is therefore worth
considering. A switch statement is easier to read than a chained
if/else. IMO, _that's_ the proper argument for a switch statement.
Trying to justify a switch statement as a way to help generate more
efficient code seems silly: This is not 1970 -- any decent compiler
should be able to generate the same code for a switch statement and
for an equivalent chained if/else.
--
Grant Edwards grant.b.edwards Yow! I want to read my new
at poem about pork brains and
gmail.com outer space ...
--
https://mail.python.org/mailman/listinfo/python-list
