Boolean tests [was Re: Attack a sacred Python Cow]

[Matthew Fitzgibbons]

Russ P. wrote:
> On Jul 30, 12:03 am, Heiko Wundram <modeln... at modelnine.org> wrote:
>> Am Mittwoch, 30. Juli 2008 08:30:48 schrieb Russ P.:
>>
>>> On Jul 29, 11:09 pm, Erik Max Francis <m... at alcyone.com> wrote:
>>>> I'm getting this sneaking suspicion that you guys are all putting us on.
>>> As I said in an earlier post, I realize that this would only work if
>>> there were only one copy of "empty" (as there is only one copy of
>>> "None"). I don't know off hand if that is feasible or not.
>>> You reply reeks of the kind of pedantic snobbishness that makes me
>>> sick.
>> I can understand (and pretty much sympathise) that you get this kind of reply,
>> simply because the point you and Carl Banks (formulated somewhat differently)
>> put up has been answered again and again (in this thread), and I can only
>> repeat it once more:
>>
>> __nonzero__(), i.e. the "cast" to boolean, is THE WAY to test whether a
>> container is empty or not. Like this design decision, or don't like it, but
>> the discussion is not going to go anywhere unless you concede that there is a
>> (very explicit!) way to test for non-emptiness of a container already, and
>> you're currently simply discussing about adding/using syntactic sugar
>> (different means of expressing the test) to suit your own personal taste
>> better. Anyway, check the documentation for __nonzero__(): if the object
>> doesn't implement that, but implements __len__(), the interpreter "replaces"
>> the __nonzero__() test by __len__()>0, so I guess someone in the design
>> department must've seen it logical for the truth value of a container to
>> express the test "len(x)>0" at some point in time to make this interpretation
>> for the truth value of a container.
>>
>> There cannot be an argument about missing/misplaced functionality (that's what
>> you make it sound like), if the functionality for doing what you want to do
>> is there and you simply don't like the syntax, which I can somewhat relate to
>> because style is a personal thing, even though I don't see either points made
>> by you or Carl Banks, because implicit casting to bool is so common in pretty
>> much every programming language to test for "truth" of an object, and IMHO
>> it's completely logical to extend that idea to containers to mean
>> empty/non-empty.
>>
>> Eric Max Francis tried to explain why your syntactic "enhancement" would come
>> at a much greater price than its worth, and he's absolutely right in that, as
>> it's an abuse of the "is" operator, but again, that's a somewhat different
>> point. It changes nothing about the fact that all this discussion centers
>> around something that is a non-point, but simply a matter of personal taste.
>>
>> --
>> Heiko Wundram
> 
> Oh, Lordy. I understand perfectly well how boolean tests, __len__, and
> __nonzero__ work in Python. It's very basic stuff. You can quit
> patronizing me (and Carl too, I'm sure).
> 
> The point that you seem to be missing, or refuse to acknowledge for
> some reason, is that  "if x" can be mistakenly applied to any object
> when the programmer thinks that x is a list -- and the programmer will
> receive no feedback on the error.
> 
> I have made errors like that, and I could have saved some time had I
> used an "empty" method that only applies to a list or other sequence.
> 
> Is that an important issue? I don't know. I'm not claiming it is. But
> you cannot just sweep it away as nothing.
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

See, I can agree with this. If you're expecting a list (and only a list) 
then your point makes sense. 'if x' can get you into trouble if you 
_don't_ want its polymorphism.

Although, if my function is expecting a list, my preference is to do:

if not isinstance(x, list):
     raise SomeMeaningfulException()
# do stuff with the list

I put my type checking at the top of the function, so readers can 
reference it easily.

However, Carl's point is that 'if x' is never preferable to the more 
verbose and slower "simple test". I do not agree with this.

-Matt