while c = f.read(1)

[Antoon Pardon]

Op 2005-08-22, Magnus Lycka schreef <lycka at carmen.se>:
> Antoon Pardon wrote:
>>>Python doesn't guess. There are a range of values that will be treated, 
>>>in a Boolean context (how perlish) as equivalent to False.
>> 
>> Yes it does. 
>
> No it doesn't!
>
>> Python has no way to know what would be the most
>> usefull Boolean interpretation of these values in a particular
>> context.
>
> It's hardly the task of the interpreter to try to do that.

Indeed ir is not, so the interpreter should not pretend it can
by providing a Boolean interpretation.

>> That it picks one out is guessing. 
>
> No, it simply follows a well defined specification.
> See http://docs.python.org/ref/Booleans.html
> There is no guessing involved in that.

Following a well defined specification is not contradictory
to guessing. It may just mean that the guess was formalized
into the specification.

>> Lisp imterprets
>> an empty list as false, scheme interprets it as true. So
>> both seem usable interpretations.
>
> You might argue that *Guido* was guessing when he decided what
> the most useful behaviour of Python would be in this case, and
> there's probably some truth in that, just as there is some
> guesswork involved in most programming language design decisions,
> but that's another thing. That's not Python guessing, it's
> Guido using his excellent lanugage design skills. It seems most
> Python programmers agree that he "guessed" right here, as usual.

I don't see a big difference. Guessing plays its roles when
different people can have different expectations in cases
where not all the details are known/specified. Whether that
is in the language design or in program design doesn't make
a big difference and I would expect that a language that
discourages guessing in the software that its written in it,
would follow its own rules in its design.

> (Perhaps you thought that "Python" was the name of the language
> designer. It's not. Python's design is led by Guido van Rossum,
> and the name Python comes from a (mostly) British comedy group.)
>
> You might also argue that this behaviour is counter to the
> Python dogma of "explicit is better than implicit". Python also
> allows you to get a float out of an expression such as "2*3.1"
> without forcing an explicit cast, as in "float(2)*3.1".
>
> You should note that the first Python tenet is "Beautiful is
> better than ugly" and that's probably what we have to blame here.
>
> There seems to be close to a consensus, that "if users:" is more
> beautiful than e.g. "if len(users) > 0:" or
> "if (len(users)==0)==False" or for that matter
> "if ((len(users)==0)==False)==True" or
> "if (((len(users)==0)==False)==True)==True" etc.

Well then I must say people here give beauty too high a priority.
Because there seems a tendency to beautify others code when
snippets are posted here. Often enough such snippets
don't give enough inoformation to know whether "if var is True:"
can be replaced by "if var:" or whether other beautifications are
appropiate. 

> What's true and false for Python, belongs to the few things you
> actually have to learn, and I can appreciate that it's annoying
> for a frequent schemer to remember that it's not the same in
> Python, but it seems that very few people argue with the way
> Python behaves in this respect.

I care very little for what someone with experience in an other
language can expect. I care about the consistence of the language
and the programs written in it. I just mentioned scheme to show
that [] interpreted as false is not so obvious as a lot of people
seem to think. Since there are situations where using '', (), []
or 0 as false would be not appropiate I advise against using them
as such, because you never know when your software that does has
to cooperate with software that doesn't.

-- 
Antoon Pardon