On Sat, May 7, 2011 at 6:05 AM, Adam Tauno Williams
<awill...@whitemice.org> wrote:
> On Fri, 2011-05-06 at 14:49 -0500, harrismh777 wrote:
>> Terry Reedy wrote:
>> >>> (2) if not li:
>> >> This is fine.
>> > This is the intended way. Anything in addition is extra noise and wasted
>> > calculation. In other words, let Python do the boilerplate work for you.
>> I agree, but I don't like it.
>
> +1 This is the Python reality-distortion-field at work.
>
> Motto#1: Python is all about readability!
> Motto#2: Crytic code is awesome if it is Pythoncally cryptic!
As a C and C++ programmer, I probably shouldn't offer an opinion, but
it is quite normal in C++ to compare objects for truth/falseness - for
instance, stream objects return false on error/eof, so you can
efficiently code a loop with "while (infile) {...}". Not to mention
that the nullness of a C string (a PSZ) is quite happily and safely
tested by seeing if the pointer is true (non-null) or false (null).
That said, though, readability is a relative thing. A construct is
transparently obvious if it does something in the exact same way that
it's always been done, no matter how obscure it was the first time.
Why is it, for instance, that putting two short strokes perpendicular
to one another indicates addition? Yet if you see the construct "x +
y", you know exactly what it means - it's readable, it's not cryptic
at all. People assume and expect that this compact syntax will be
available, and object heavily to such notation as "add(x,y)" which
says exactly what it does.
if not li:
is perfectly readable; you just need a comprehension of what truth
means for a list.
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
