Coding style

[Carl Banks]

Bruno Desthuilliers wrote:
> Carl Banks wrote:
> > Iterables, lists, arrays, and whatever else have overlapping uses, but
> > bool(obj) behaves differently for different types,
>
> bool(obj) will mainly look for __len__(), then for __nonzero__(), then
> return True. You can only call len(obj) on objects implementing
> __len__(), so relying on (implicit) 'bool(obj)' is clearly more generic
> than 'len(obj) > 0'.  Also, since bool(obj) will try to call
> obj.__len__(), explicitely calling len(obj) doesn't make any difference.

I'm well aware of Python's semantics, and it's irrelvant to my
argument.  What low level operations it does do not concern me.  I'm
concerned about what equats to "truth".  For generators and such, it's
"always".  For lists, it's "empty".  For numpy arrays, there is no
truth value.

For the purpose of writing generic functions, this is inconsistent.
And, IMO, it's possible that the language would have been designed
differently (by not letting them have any truth value) if they'd been
around in the beginning.


> And if you want your own sequence types to be well-behaved sequence
> types, just take time to implement the needed protocol(s), including
> __len__().

You know very well that not all iterables can know their length ahead
of time.


> For short: either your function expects an iterable or it expects a
> sequence. If it expects an iterable, treat it as an iterable wether it
> happens to be a sequence or not.

1. This is fine in a perfect world where all code clearly conforms to
expectation.  Problem is, a lot doesn't.  I think it's quite easy to
accidentally check something intended as an iterable for emptiness.
And, as I've explained in other posts, this can lead to subtle bugs.
Whereas if you check for emptiness using len, it throws an exception
right away, no bugs.  It's safer to use len.  (Safest of all is not to
check for emptiness at all.)

2. This logic doesn't work for numpy arrays.  In a lot of cases, a
function expecting a list works perfectly fine if you pass it a numpy
arrray.  But, if you were to write such a function with "if lst"
instead of "if len(lst)>0", it's guaranteed to fail.  The function is
more generic with the len test.


> > it's possible that these types wouldn't even have a boolean
> > value and any tests for emptiness would have to be explicit.
>
> Yes ? How ? Calling len() on them ?-)
> (hint: reread how len() and bool() works wrt/ __len__())

Yes.  If the language had been designed such that a list had no
nb_nonzero slot, you'd have to check for emptiness with len.  Perhaps
you're missing some of the nuances of English verb tenses (don't feel
too bad, it's hard).  I'm not arguing "what is", I'm arguing what
"could have been if circumstances were different".  If the language
were designed differently, then the rules would be different.


Carl Banks