On Wed, Sep 13, 2017 at 1:01 PM, Rick Johnson
<rantingrickjohn...@gmail.com> wrote:
> Chris Angelico wrote:
>> Rick Johnson wrote:
>> > So, what are your answers to my four questions:
>> >
>
> I told you to forget about the superfluous lambda, but
> alas, you cannot :-(
You told me to forget about the key thing I was making my point about,
and yet insisted on answers to your four questions?
> 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".
The statement "if x:" is not shorthand for any sort of equality
comparison. If you want to say that it's shorthand for "if bool(x):",
then sure, but the "== True" part is entirely superfluous.
> What are the moral principals of language design?
PEP 20.
> 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...
"Anything on that list?" is far more idiomatic English than "Is the
boolean value of that list identical to the constant True?".
> 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.
Actually, you're absolutely correct. You can make them execute just as
quickly. Here:
class X:
def __bool__(self):
while True is not False:
pass
x = X()
Easy.
> There is absolutely no correlation between the length of a
> statement and the time required to execute that statement
> once it has been "interpreted".
> [chomp]
> ...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.
So you start with the assumption that "if bool(x) is True" and "if x"
have absolutely identical semantics, and then say that they should be
the same thing. Great! Well, when they do, you can remind someone to
improve the peephole optimizer. Turns out, "bool(x)" is slower because
it has different semantics. What an enormous surprise.
> 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.
Yep. So, where are you going to draw the line between "absurd" and
"correct"? I'm going to put it just after "if x:", on the basis that
all superfluous code is bad. Justify the amount of superfluous code
that you want.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
