while (thread.alive()):

[Alex Martelli]

"Jay O'Connor" <joconnor at cybermesa.com> wrote in message
news:mailman.977283904.26696.python-list at python.org...
    [snip]
> Believe it or not, both Ada and Smalltalk have boolean types.

So does Fortran.  It calls them 'LOGICAL'.  So?

> Both languages were designed in the 70s, commercially implemented in the
> 80s; one is dynamically typed, one is statically typed.

And Fortran was first designed and implemented in the '50s (although
I'm not sure if the 1954 version already had LOGICAL).  So?

> Why are we still maintaining these leftover idioms such as using
> integers as booleans.  If we are to carry the state of the art of
> programming beyond it's current level, we need to be programming a t a
> higher level of abstraction than is easily supported while still
> dragging anachronisms such as this around.

The idea of having LOGICAL (or Boolean, whatever) as a separate
type is far older -- as old as the oldest surviving high-level
language.  C, which introduced the simplification of NOT having
a separate boolean type although generally moving towards precise
typing (which its inspiration-language, BCPL, didn't), came much
later.  So how can you possibly claim the _newer_ notion is an
"anachronism"?!  If 'when was it invented' had anything to do
with the issue (and it's, IMHO, quite silly to claim it does),
then the 'anachronism' would have to be the older notion of
having LOGICAL as a separate type.

As for abstraction,
    if anyobject:
        # whatever
is quite high-abstraction enough for me: whatever 'anyobject'
is referring to will define its own interpretation of 'being
false' -- polymorphically and in a perfectly abstract way.


> Those who claim that 'while 1:' is obvious, it's not.

Neither is 'X=X+1' *obvious* _at all_, to somebody who has
never programmed; I remember, on my first encounter with
programming, that it was the thing that puzzled me most --
"no, X does *NOT* equal X+1, what's this silliness?!".  That
doesn't necessarily mean Python should adopt <- to indicate
'assignment' (although, except for the backwards compatibility
issue, and the parsing problems betwen 'x < (-2)' and assignment
of 2 to x, I wouldn't mind it -- ':=', now, THAT would be
a bad choice indeed...:-).  The very specialized meanings of
'=' in some languages (Fortran, PL/I, C, C++, Java, Python,
Basic, &c) become reasonably clear with a *very* modest
amount of study -- if only all programming issues were
as easy to grasp as such surface-syntax-sugar ones!-)


> It's only obvious if you've programmed "C" and other such languages.
> It's makes no sense really, unless you've learned the 'code

And you claim that
    while 'true':
would be enormously clearer to a beginner, without study, than
    while 1:
...?  Ridiculous claim, but, go ahead -- use "while 'true':" and be
happy, Python won't complain in the least.


> My first professional language was Ada83.  From there I went to
> Smalltalk.  When I finally started working with languages such as C,
> C++, etc... I was at first confused ( while (1)...what does that mean)
> and then revolted.
>
> I'm continuously amused that people try to take language design forward
> and still drag obsolete ideas along for the ride.
>
> Python's got a lot of cool stuff, but the lack of a real Boolean object
> is a glaring omission

And once again, you have completely failed to make any case for
it.  Your very personal aesthetical preferences, as shaped by
Ada or Smalltalk, are no 'case' at all, of course; just *show*
us what a Python-plus-boolean-type would enable, as the payback
of the needed additions to the language, that current Python
doesn't.  Vacuous claims of 'obsolete' are made particularly
ridiculous by your apparent (and erroneous) beliefs regarding
dates of introduction in typed-languages of 'logical as a
separate type' vs removal of this type-distinction -- as if
the 'dates of invention' mattered at all, of course.

*Entities are not to be multiplied needlessly".  So, show the
NEED -- the NECESSITY for this additional *entity*; the actual,
practical benefits it would bring.  (If you want *several*
additional entities, be sure to assert and justify each of
them).

Be sure to state CLEARLY (that would be the day...) which
proposals are meant for Python-as-it-stands (no introduction
of backwards incompatibilities, as, for example, additional
reserved-words would imply), and which ones for Py3K-of-
the-future (incompatibilities admitted, it the resulting
benefits are really really big)...


Alex