I'm not questioning whether it's broken or not, just stating
that this is a likely mistake for people to make. Especially
since the latter case does work if expr is the result of an
operation with a logical result but not for other expressions
that are often used in a logical context.
I probably should have used "expr_result" rather than "expr".
I really meant for "expr" to be a variable, and was thinking
about the case where you would do this:
expr = ...some expression with a "logical" outcome...
if not expr:
....
In a strongly-typed language, this isn't an issue, since
you'd have declared "expr" as a boolean type. In that case,
"not expr" is the same as "expr == False".
Considering Python's roots as a teaching language, it would
be preferable to immediately catch situations where Boolean
values are compared to non-Boolean ones and do *something*
about it.
-Jerry
-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O-
-O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O-
-O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O-
Paul Svensson wrote:
> On Mon, 1 Apr 2002, Gerald S. Williams wrote:
> >Consider that the main source of confusion won't come from
> >comparisons to True, but comparisons to False. These two
> >statements might look identical to the casual observer, but
> >they really aren't:
> >
> > if not expr:
> >
> > if expr == False:
>
> Of course they aren't;
> the first example is good code,
> the second is broken,
> and deserves to lose.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4