Coding style

[Antoon Pardon]

On 2006-07-19, Donn Cave <donn at u.washington.edu> wrote:
> In article <e9ksvr$g8u$1 at news.albasani.net>,
>  Georg Brandl <g.brandl-nospam at gmx.net> wrote:
>> Lawrence D'Oliveiro wrote:
>
>> > One of my rules is, always program like the language actually has a Boolean
>> > type, even if it doesn't. That means, never assume that arbitrary values
>> > can be interpreted as true or false, always put in an explicit comparison
>> > if necessary so it's obvious the expression is a Boolean.
>> 
>> You can do that, but it's not considered Pythonic. And it might be 
>> ineffective.
>> 
>> Other than in PHP, Python has clear rules when an object of a builtin type
>> is considered false (i.e. when it's empty). So why not take advantage of
>> this?
>
> I don't know whether she would welcome this or not, but here
> I provide an archive link to a classic post by Laura Creighton
> on this matter:
>
> http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360
>
> It's lengthy but very readable, and for me it has that quality of
> exposition where you feel at first reading as though you had
> already known all that -- even if you really hadn't.

Well for me it wasn't, I don't agree with it at all.

IMO, whether something is to be considered "True" or "False"
is application dependent. There are cases where I would
consider an empty sequence as True, because a sequence in
itself would mean, continue and the members would be
the current available elements to be processed.

Nothing is IMO not specific enough and doesn't make
the disctinction between nothing (temporarily) now
and nothing more (for ever).

That is why I think the distinction between True and
False is more usefull than the distinction between
nothing and something.

-- 
Antoon Pardon