Chris Angelico wrote:
> Rick Johnson wrote:
> > So, what are your answers to my four questions:
> >
> > (1) Is it a speed issue? Then prove it.
> >
> > (2) Is it a readability issue? If so, then that's an
> > opinion _you_ get to have.
> >
> > (3) Is it a matter of "python purity"? If so, then map
> > should be removed from the language, and don't forget to
> > remove reduce and filter while you're at it, and then,
> > you may want to grab a shield because the functional
> > fanboys will be all over you like white on rice! (psst:
> > here comes Rustom Mody now!!!)
> >
> > (4) Something else...?
>
>
> (Oops, premature send.)
It's okay Chris, it happens. Sometimes we get a little too
excited and loose all control over our bodily functions. O:-)
> #1 is almost certainly true, since non-code is invariably
> faster than code (either way, int() gets called). But
> that's not the point.
I told you to forget about the superfluous lambda, but
alas, you cannot :-(
> #2 is part of the point. But not the main point.
>
> #3 - if you mean that map violates purity in some way, then
> (a) I never said to remove it, and (b) Python never brags
> that purity is its goal.
If you wanted to say no, you could have just said it...
> #4. Catch-all, I guess.
>
> Do you write:
> if x:
>
> or do you write:
> if bool(x):
>
> or maybe:
> if bool(x) is True:
>
> or perhaps:
> if (bool(x) is True) is True:
>
> or even:
> if (bool(x) is True) == (True is not False):
>
> Redundant code does not belong.
Just as writing overly implicit code is harmful, so too is
writing overly explicit code.
When we read overly implicit code, we are distracted by the
need to interpret the enormous amount of meaning hiding
behind a single symbol. Regular expressions are an example
of overly implicit code, but regular expressions are a
special purpose tool, and they are designed with the idea of
packing a lot of functionality into the fewest symbols.
OTOH, when we read overly explicit code, we are distracted
by the excessive symbols.
So a balance must be found between these two extremes. For
instance, i have always considered this "Python custom" to
be far too implicit:
if x:
# do something
What are we testing about `x`?
Obviously, most programmers, especially Python programmers,
will know what is going on here because they have been
trained, and just like any child who has been trained to
ride a bicycle, riding a bicycle becomes _reflexive_, and
the rider, who was once terrified of riding, becomes cocky,
as to them the task now seems simple.
But just because we have been trained that the implicit `if
x:` is shorthand for the reasonable `if bool(x) == True:`,
does not mean the implicit syntax is "correct". No. You,
just as the child who learned to ride a bicycle now believes
that `if x` is right, and not because of some deep objective
analysis, no, but because it is "reflexive" for you to say
so. Your failure here is obvious: you're conflating
Pavlovian conditioning with moral principals.
What are the moral principals of language design?
A tough question to answer objectively, i admit, however, if
we can manage to see beyond their own subjective
interpretations of reality, most of which that have been
molded by years of obedience training (aka: "Oh, that's
soooooo easy because my master said so, and peer pressure
demands it"), then we might find the objective compromise
between two extremes. In this case, the compromise is:
if bool(x) is True:
# do something...
In this example, we strike a balance between implicit and
explicit code, because in this example, we don't need to
assume what aspect of `x` that we are "testing", no, because
the test is now made crystal clear. We can even expand the
code to English intuitively, as:
if the boolean value of x is True:
# do something...
Now, some quippy person will no doubt complain that: `if
bool(x) is True` will be slower than `if x`. And that's
true! But the reason it's slower is not because it's a bad
idea, no, it's because the language designers have decided
(via emotion, not logic!) that `if x` is the better way to
go, and so they've optimized `if x`. I assure you that, `if
bool(x) is True` can be made to execute exactly as fast as
`if x`, and anybody who claims otherwise is a flat out liar.
There is absolutely no correlation between the length of a
statement and the time required to execute that statement
once it has been "interpreted". Heck, if we wanted to be
silly, we could expand the statement to:
if the boolean value of x is True\
and python is absolutely one hundred percent positive that it is True\
and furthermore there is not even a snowballs chance in hell that it
could be False\
and the earth is roundish\
and water is wet\
and OJ is not looking for the true killer because he would rather play
golf\
and mass media is a tool of corporate america\
and most people are a tool of corporate america\
and being a tool is totally not cool\
and reality TV is totally scripted\
and politicians will say anything to get elected\
and money has corrupted our elections\
and money has corrupted all of us\
and iphones are made in sweat shops\
and so are our name brand tennis shoes\
and Fakebook really is spying on us\
and so is Google\
and if we call either one out they will only deny it\
and use it as an excuse to institutionalize us\
and then we will meet nurse Ratchet\
and she will torment us with her microphone\
and then we will be asphyxiated by Big Chief\
and then Chief will escape the nest of cookoos\
and the BDFL once claimed he would ride in a plane controlled by a
python script\
and he meant it\
and no i am not joking:
#
# WHEW! Okay, then i guess you can do something...
#
...and the byte compiled code would execute at the same
speed as `if x`. And if it doesn't, then the devs are
incompetent or they're sabotaging the interpreter for
political reasons.
And as far as your other examples are concerned:
> or perhaps:
> if (bool(x) is True) is True:
>
> or even:
> if (bool(x) is True) == (True is not False):
they're just reductio ad absurdum.
--
https://mail.python.org/mailman/listinfo/python-list
