On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> >
> > >
> > > I would agree that testing any of those for '== True' or
> > > the like is pointless redundancy,
> >
> > But what's wrong with syntactical redundancy when it brings
> > _clarity_ to the source code? And why can't Python be smart?
> > Consider the collowing code:
> >
> > if bool(someObject) == True:
> > # Do something
> >
> > Yes, from a "byte-code perspective", this source code is
> > superfluous, but, from a source code perspective, this code
> > is perfectly balanced between explicit and implicit.
>
> I can't agree with you. It's too redundant. It doesn't
> provide any information about what coder think.
It's not about what the "coder thinks", many times what the
coder thinks is wrong, it's about writing code that is
intuitive to as wide an audience as possible.
> While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> len(x) > 0` when I review code in my company.
So when `x` is an iterable, as in:
if len(x) > 0:
# blah
You're okay with the explicit test. Or when `x` is a
numeric, as in:
if x > 0:
# blah
You're okay with the explicit test. So, from a standpoint of
consistency, you /should/ be okay with this:
if bool(x) == True:
# blah
But you're not! :-).
Even though "== True" is just as much a part of the explicit
test as "> 0" is, and likewise, "bool(x)" is just as important
as "len(x)" to call the proper dunder method. So what is
your justification for making a special case out of the last
example, but having no problem with the first two forms?
Because, as we know: "SPECIAL CASES ARE NOT SPECIAL ENOUGH
TO BREAK THE RULES". *wink*
IMO, you're ignoring the importance of consistency. If you
want to be consistent, either you must accept _all_ forms,
or _none_ of them.
> While it is redundant in most case, it express what writer
> thinking. But I never permit `if bool(x) == True`. It only
> express `if x is truthy value` in complicated way. `if x`
> is best way to express `if x is truthy value`.
Tell you what: test your hypothesis on non-programmers and
report back here.
> > So what
> > should Python do when such intuitive, but not so much
> > efficient, code is encountered? Easy! Python should optimize
> > it! Observe:
> >
> > FROM: "if bool(someObject) == True:"
> > TO: "if someObject:"
> >
> > FROM: "if bool(someObject) == False:"
> > TO: "if not someObject:"
> >
> > Why is "source code optimization" such a difficult concept
> > for some people in this community to grasp? In this case,
> > Python doesn't even need to know anything about these
> > objects, no, the solution is just a simple matter of string
> > substitution.
> >
> >
> While such type of optimization is possible, it's not easy
> as you think. You can overwrite `bool`.
>
> def bool(x):
> return !x
Oops. That looks like a syntax error. Ruby uses the "!" as a
logical not operator, _not_ Python.
> if 0:
> print("not shown")
>
> if bool(0) == True:
> print("shown")
>
But i get your point.
Although, your point -- "that a programmer can shoot
[him/her]self in the foot" -- is really moot, since there are
literally countless ways in which code can be broken by
doing dumb things. For example, i can hit my computer with a
big hammer and cause all sorts of bad things to happen, but
using the: "coder might strike the computer with big hammer
so we should prepare for that by doing X, Y and Z..." excuse
as a design philosophy is just not practical. In the end,
we can't stop a coder from smashing the computer with a big
hammer, but we can demand that the code is written in an
explicit (enough) manner.
Forcing whitespace usage to denote Python blocks is one way
that Python forces us to write clean code, and all i'm
suggesting is an extrapolation of that philosophy into the
realms of conditional logic.
> But my point is only readability. I don't agree `if
> bool(x) == True:` is clear than `if x:`.
You certainly have a right to your opinion. And i do
appreciate you presenting this argument in a respectful
manner.
I'm thinking of writing a linter (or pre-parser, call it
what you like) that will enforce the explicit forms that i
have outlined above. Possibly with the ability to fine tune
it in a way that best suits the programmer. For instance, if
you wanted "if NUMERIC > 0" and "if len(ITERABLE) > 0", but
you didn't want "if bool(x) == BOOLEAN_LITERAL", then it
would ignore the last form.
What do you think of this?
--
https://mail.python.org/mailman/listinfo/python-list
