osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tutor] beginning to code


>
> >
> > 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.
>

My point is not "what the coder thinks", but "express what the coder
thinks".
It's very important point about readability.

When I talk about readability, it's defined in "The Art of Readable Code".
http://shop.oreilly.com/product/9780596802301.do

It means; How long average leveled programmer understand the code
deep enough, to modify the code or fix bug in the code.

It not means "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.


Yes, you know "this code is assuming x is container" from redundant `len(x)
> 0`.
It's valuable information.
As a bonus, len(x) raises TypeError and program stops, (and transaction
will be rolled back)
when x is None.


Or when `x` is a numeric, as in:


>     if x > 0:
>         # blah
>
> You're okay with the explicit test.


Yes, you know this code assumes x is numeric.  `if x:` doesn't tell the
information to you.
As a bonus, if x is None, `x > 0` raises TypeError on Python 3.



> So, from a standpoint of
> consistency, you /should/ be okay with this:
>
>     if bool(x) == True:
>         # blah
>
> But you're not! :-).
>

I don't accept it because `if bool(x) == True` doesn't give any information
than `if x:`.
Both mean just `if x is truthy`.  No more information.
Redundant code is just a noise.


>
> 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?
>

Already described above.  Give more information to reader
who is average leveled Pythonista or not.


>
> Because, as we know: "SPECIAL CASES ARE NOT SPECIAL ENOUGH
> TO BREAK THE RULES". *wink*
>

That's why I don't write such code in CPython stdlib.
I allow such code only in my company or OSS project I maintain.


>
> IMO, you're ignoring the importance of consistency. If you
> want to be consistent, either you must accept _all_ forms,
> or _none_ of them.
>

As I already describe, I'm  very consistent.
Redundant code is meaningful only when it gives valuable information
to reader.  Otherwise, it's noise.  It should be removed.


>
> > 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.
>

I can't agree with you here.
And who agree with you in this thread?

> 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.
>
>
Sorry.  Writing Python in gmail textarea is bad experience.



> Although, your point -- "that a programmer can shoot
> [him/her]self in the foot" -- is really moot,


No, it's not my point.
My point is just optimizing `bool(x) == True` is not easy as static
language.
Optimizer must be very very conservative about changing language behavior.


> 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?
>

I don't want it.
I don't reject "if x > 0:` when codereview.  But I don't recommend it too.

Regards,
-- 
Inada Naoki <songofacandy at gmail.com>