while true: !!!

[Alex Martelli]

"D-Man" <dsh8290 at rit.edu> wrote in message
news:mailman.977147642.18708.python-list at python.org...
> > It is cheap to define true and false once,
>
> I think that some people were confused with this statement.  He meant
> that 'true' and 'false' would be constants like in C++ and Java.  It
> would be illegal to try
>
> true = false
>
> Thus while true: is equal to while 1: except that a boolean, not an
> integer is used for the test.  I, for one, would like to abolish the
> concept that an integer can denote true or false.  How many functions
> return 0 for success?  (just take a look at the standard C library).

Depending on how you define 'success', 0 is a pretty popular
'success' return-value, with a return value != 0 defining an
error-code.  That is how C's main() function works, for
example; it's also the COM binary standard (but, in the COM
mappings for languages that have the concept of 'exception',
COM error returns are mapped into exceptions -- however, the
binary standard is defined so it can be handled by C code,
and thus cannot rely on the concept of 'exception').

Few languages equate 'success' (not raising an exception, for
languages where 'exception' means something) with 'a boolean
result' (Icon is rather oriented that way, but that's because
it _backtracks_ over 'insuccess' -- a very different setup
than Python's).  And such a mapping would not be very normal,
natural, or idiomatic in Python, though you can get it, if
you want, by wrapping things up to convert true/false results
to not-raise/raise or vice versa.

An explicit Boolean type is very useful in languages where
you can define *overloads* based upon it -- i.e., reasonably
advanced languages with static typesystems; that is specifically
the reason for the design decision to add it to C++, for
example (see Stroustrup's "Design and Evolution" book), though
keeping _also_ the C convention (inevitable, for backwards
compatibility) makes things pretty awkward sometimes.

In a language without overloads, and, more generally, without
static typechecking, it's hard to see what adding such a type
buys you.  Presumably, you'd have to add a type conversion
function, say 'boolean', and most of the current if and while
statements would become "if boolean(whatever):" (assuming
you're not as careful about backwards compatibility as C++
always was -- else, nothing at all would change, and you'd
just have the slight conceptual cost of another elementary
type in the language _without_ any extra feature coming from
its presence...?).

I think it would be inconsistent, un-Pythonic, to add a
fundamental type for 'conceptual' reasons, without any
practical, measurable benefit.  For example, Python does
away with the distinction between 'a character' and 'a
string of length 1' -- a distinction that is religiously
maintained in C, Pascal, Java, etc, and does have a basis
in both 'conceptual' and machine-level considerations --
yet the strong conceptual *simplification* arising from
just doing away with the distinction appears to be quite
positive.  Practical benefits -- constructs, idioms,
patterns, of real interest, that are now awkward or
impossible, and would become easy or at least possible --
had better be exhibited, and shown not to reduce to
duplicating what is best done with exceptions (success
vs failure issues) or lead to 'type-switches' (a horrid
meta-idiom that one would love to _stamp out_, rather
than _encouraging_ it...:-).

Note that a *separate* case would have to be made for
the existence of "constants like in C++ and Java"; this
is another concept which Python does not currently
support (without much noticeable loss, altough, in
this case, I think it's more open to discussion).  I
suggest not arguing for two separate fundamental changes
to the language in the same breath -- I think getting
the BDFL to accept _one_ such change will already be
plenty hard enough:-)


Alex